From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81757C6FD1D for ; Thu, 30 Mar 2023 12:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E17AA900002; Thu, 30 Mar 2023 08:07:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC8836B0074; Thu, 30 Mar 2023 08:07:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9082900002; Thu, 30 Mar 2023 08:07:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B71DF6B0072 for ; Thu, 30 Mar 2023 08:07:03 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7BE9F120940 for ; Thu, 30 Mar 2023 12:07:03 +0000 (UTC) X-FDA: 80625438726.25.8D78A59 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf01.hostedemail.com (Postfix) with ESMTP id 8D1764001B for ; Thu, 30 Mar 2023 12:07:00 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="GicAwO0/"; spf=pass (imf01.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.214.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680178020; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Z2gBu0cd56okBmgzR+FM39ycpsQMxjUJpB7f1n614EA=; b=mNPS2qSE4ufLIPN7ALogNuwW7jJw4S2YcSZ0ZpmSQpzdOISPZgFDKYGeiEelanS4J5m7R6 O+sHH+mN6sOZiKvNCYXTs/07YMOQWimsKzloQh/+tWVu5OSL05cyqM5ebx+le6gZonY3XS gyMyOOAghMYKn+knQqMHw4JZKod4uCw= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="GicAwO0/"; spf=pass (imf01.hostedemail.com: domain of xu.xin.sc@gmail.com designates 209.85.214.193 as permitted sender) smtp.mailfrom=xu.xin.sc@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680178020; a=rsa-sha256; cv=none; b=wX6UpSexGq1PbKd1REwIbgVRHlNM/a3GdAkoH+LGetgoDKyuDO/gld3aagFHPjoGpgPSL1 S7zWPiHm9ro2jcbCkOrCYZRXo64y2AEnLVvlYaHzbguCBG+u3JqgrNm+3uXSN/Me6P/a8m Sjw5hM/Ger9kjIgEUj7r/OZwc/hp/Eo= Received: by mail-pl1-f193.google.com with SMTP id z19so17863309plo.2 for ; Thu, 30 Mar 2023 05:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680178019; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Z2gBu0cd56okBmgzR+FM39ycpsQMxjUJpB7f1n614EA=; b=GicAwO0/B1GYQYs19bT/t/pZlHMPISuoBxHxVjM3tAxbxQp67F614LMvDlh+YgPD0/ h4AZ/D64h/F4EbJdnyKNrkDIViZBed+z+ExP06XqF8jl5bQQ27ii7dzg/RGCuosft7Yx QAtFliPjJ6vOkF/e1EGdeyHgSpjpTefNvRl6B5cmfsGr/LT4WU7f3dqL99UR5Hfez0lI IoIijvCbPjwhyuNkC3ZxVaoAZTOkyOf2ZbKaOnpC4rDf1SBQZTesSGWamWHT1svIcWK3 Z1KnQAi0nXxH1Ye28dc5UMrF4V3yluCT7isGhYrgyEff+2EB16I9lHj9BEs5KXci8KhJ PyXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680178019; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z2gBu0cd56okBmgzR+FM39ycpsQMxjUJpB7f1n614EA=; b=2w4sd+xBYtuJMGhchMB2VXJAl+HIWU3kAMRLXnIZIxlbyrTMY2B3nOtzQ7GxMhftIl ESz1mHJY3Lk0KEFppl92z00hStbSUCMCFQ73eS9U5xB+N6Hktn5yN1Hvop5IT7at6c4V HxOiGJLtmklzZWkFk6PXndfRUc6unr7VgbmJHKSZ/mJnOSI2iqpceE8vqcZSuCUi+Nmy 4Tje23DXAz1MOnPFlIElXMEYiM83JjE7sH2uFUJRApWB7jn72gFyBgM7ga+qkmyhF5AU bGBHKcfrEcKI8cXU0Da5Mb41RvO2fCsArqBW4FO9+4eMPol6i7PWbMc6psFSz5CxUXop cL/Q== X-Gm-Message-State: AO0yUKVSrPa7gwwKuyhRYYAI+wpsWpb1JLW8EEBeyRZegpSHnAhnhMNK 0djGYvleHGSm0YQiyoHueic= X-Google-Smtp-Source: AK7set+4uqlqFfPED8zRNgqghXHa4HmDT6d/nF9VLxEkI+X1TT9Tq2pkT3vQ9iXuM+03v3kVbyx3Lw== X-Received: by 2002:a05:6a20:651c:b0:d8:d0e5:df90 with SMTP id n28-20020a056a20651c00b000d8d0e5df90mr20181565pzg.44.1680178019021; Thu, 30 Mar 2023 05:06:59 -0700 (PDT) Received: from localhost.localdomain ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id u14-20020a62ed0e000000b006242f4a8945sm24665653pfh.182.2023.03.30.05.06.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Mar 2023 05:06:58 -0700 (PDT) From: xu xin X-Google-Original-From: xu xin To: david@redhat.com Cc: akpm@linux-foundation.org, imbrenda@linux.ibm.com, jiang.xuexin@zte.com.cn, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ran.xiaokai@zte.com.cn, xu.xin.sc@gmail.com, xu.xin16@zte.com.cn, yang.yang29@zte.com.cn Subject: Re: [PATCH v6 0/6] ksm: support tracking KSM-placed zero-pages Date: Thu, 30 Mar 2023 12:06:54 +0000 Message-Id: <20230330120654.120937-1-xu.xin16@zte.com.cn> X-Mailer: git-send-email 2.25.1 In-Reply-To: <78e35d88-8a4e-3b36-bbbd-94048c0c5b54@redhat.com> References: <78e35d88-8a4e-3b36-bbbd-94048c0c5b54@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8D1764001B X-Rspam-User: X-Stat-Signature: jkiux5n9zt74rex3x9prmtcgocp6dosf X-HE-Tag: 1680178020-95811 X-HE-Meta: U2FsdGVkX1/92zB3v9W0w6HHtiHt+tS1VEbEpovg9YxPunBaRLveJGUgoqFbzAsUt8aG4kHJ5CnhORzNRmEtc8Y7AvXDwXMJQPYeBnemwMXENgp5YAvUdVd8I6i8Io7mOJvzqON6TjbynADGVLVcPZOWCPG5lZ7Unw8Ivf6KmWw6JI6otlEjC/Fe+PPIf2RwEA6KYCC+ugwc4J92ylBsY5fUnqyEQ+DolPaFVeSNODNBROHUbKSDXm619Yacu7GZtrhYSOMN5qUOBD3mKTTrZwMMqrX9vNl3M49Bvd+eT66YhouYyFBIsm4WGIniqrMZA1RUBQW2I2AL50Nss5yuGmg3PhABOUIgHX0IzRgbMvOlnwrFyJwOADNO1AoNeqAO6FqGnuxQuy/Wz+6wixexqISsbm6I+YrneDCLvTcZIKJJODBvmA+dYjKlWGtkUQP349r6+vFhEWp++Kt+65sENZAoj9IJyxV2pRcnxEx93oW57AqFfZRon/eUrWyMM1soycDhwCBRZ+6D9pQvinFbaTts0E/oAg/8lNQPwRLIrMgXac4MYZ5rQH7FnKQDxCPJ+n//slyn2AzItNMrHo9b8tE74nJN7YPkppDbjPag2enhZVzGZi+u6qETi9bpaDiTPhY8zHPF6IG18XA1cuip7C6XEtkWhqqF20b2TzrjBjP/CrqgPeL10SQitAtsejbWvJGpzZtaDExpWQ7ZiaJqSiQXpfTt/LJEu1betaOliJ5VhTil//aotMtZhYVFkOWUFSWURsUnCptx/TcfSX/H93lZghi7ggfPXY1wtiBgvtTnXS7aGotaMe3V7yLZQwRS7+RBrE9hVnZM4T9B1J7fzFhc0Lwz4BW9hpbZ8mzLVomUinVBgOLfEB/nQ9rky/vC/puJw5AZQZIf2p8PBRM7ymXyzj5zvcbs4fzr0x0vlJNSMf3Y0kjdPxpjkW8QZdsCiy+7pnHejof6Hd9H+Ex wVIvwkyr jVuqveWx3UqZRkEBE5YYzkXjd/9OIasLaGlkFoUmwVLN6aRBJSKqtR59wQUdhmXiyZiroUcqadGwaCptr/vJDOBrj6I4svdE2gzg+zU4WG7UgKRqllXGQl7QV17B3I6hbdg6hYXJt1Sp7az/XAFynYHhlYQAUfQHA63NSbfWvCOJiCP8wS4Bz0zMxH6wVvZpnJAeC7Vkf4Yqe7s6zwBb2hMFhf1/7XChNGh+fHWGwPFuTSufbTXoTuJ2zxw6+nZmG2IP0qa3FE2iYFu6bWC2m8cStE/biMD5TuM1XV3DALeiAaaZe3ZzYi37pwEvN7eybIVEaI+gNWsfg++kPWnIAq4qmVptioLPrXfdMjDONG58QhO/TpQHgcTsigo8G+nBNMqWeSKKQgwzm18MsGK9NiAI1t0FO4vseT5tRPT29I7mboKkPJUjIP0CME91sGzm3laRvj9OtBmsnfMPzR6Ij+e4k5vJxeZd0ZPx+pVEBCtuDVHZt9k0ZIpKSDRda1jxoBLAXjOzk+QVZaI8d12O/MZhJ4uBEYLXyT94Bfm41InZCobsH7fwFBFTYnMze/A9FYCwqh3hmiZ+WssYTPzJVHfmV0olq5C139g8U X-Bogosity: Ham, tests=bogofilter, spamicity=0.000959, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, I'm sorry to reply so late because I was so busy with my job matters recently. I appreciate David's idea of simplifying the implement of tracking KSM-placed zero pages. But I'm confused with how to implement that via pte_mkdirty/pte_dirty without affecting other functions now and in the future. > >I already shared some feedback in [1]. I think we should try to simplify >this handling, as proposed in that mail. Still waiting for a reply. > >[1] >https://lore.kernel.org/all/9d7a8be3-ee9e-3492-841b-a0af9952ef36@redhat.com/ I have some questions about using pte_mkdirty to mark KSM-placed zero pages. (1) Will KSM using pte_mkdirty to mark KSM-placed zero pages collides with the existing handling of the same pte in other featutes? And in the future, what if there are new codes also using pte_mkdirty for other goals. (2) Can the literal meaning of pte_mkdiry represents a pte that points to ksm zero page? (3) Suppose we use the pte_mkdirty approach, how to update/decline the count of ksm_zero_pages when upper app writting on the page triggers COW(Copy on Write)? In *mm_fault outside mm/ksm.c ? Move the previos message here to reply together. >The problem with this approach I see is that it fundamentally relies on >the rmap/stable-tree to detect whether a zeropage was placed or not. > >I was wondering, why we even need an rmap item *at all* anymore. Why >can't we place the shared zeropage an call it a day (remove the rmap >item)? Once we placed a shared zeropage, the next KSM scan should better >just ignore it, it's already deduplicated. The reason is as follows ... Initially, all scanned pages by ksmd will be assigned a rmap_item storing the page information and ksm information, which helps ksmd can know every scanned pages' status and update all counts especialy when COW happens. But since use_zero_pages feature was merged, the situation changed, ksm zero pages is the only exception of ksm-scanned page without owning a rmap_item in KSM, which leads to ksmd even don't know the existing of KSM-placed, and thus causes the problem of our patches aimed to solve.