public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: xu.xin16@zte.com.cn, shr@devkernel.io, ljs@kernel.org
Cc: hughd@google.com, akpm@linux-foundation.org,
	chengming.zhou@linux.dev, wang.yaxin@zte.com.cn,
	yang.yang29@zte.com.cn, michel@lespinasse.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: 答复: [PATCH v3 2/2] ksm: Optimize rmap_walk_ksm by passing a suitable address range
Date: Thu, 9 Apr 2026 14:26:31 +0200	[thread overview]
Message-ID: <a2d43c08-984e-4ccf-9faf-abefe0f931b0@kernel.org> (raw)
In-Reply-To: <d473917c-468b-46d0-adfd-b8a1d075f8b2@kernel.org>

On 4/9/26 13:59, David Hildenbrand (Arm) wrote:
> On 4/9/26 12:56, xu.xin16@zte.com.cn wrote:
>>>
>>> Hmm, maybe we could do the following. I think the other members are only
>>> relevant for the unstable tree.
>>
>> Well, I suspect that "SmartScan-Related" members might be also needed and used even when
>>
>> it's a stable rmap_item. In should_skip_rmap_item(), if its page is KSM, it can't be skip.
> 
> Yes, needs some more thought on details. We might have to ignore/skip
> the fields for stable tree entries that have not a KSM page.
> 
>>
>> What if the rmap_item is stable, but its page is not KSM?
> 
> I guess that would happen if we had a rmap_item at that address, and
> then changed the page (e.g., COW).
> 
> ksm_do_scan() would call cmp_and_merge_page() after obtaining such an
> rmap item from scan_get_next_rmap_item().
> 
> In cmp_and_merge_page() we'd call remove_rmap_item_from_tree() and
> recalculate the checksum.
> 
> In remove_rmap_item_from_tree() we remove the item from the stable tree.
> 
> So we'd want to ignore the entries in STABLE_FLAG in
> scan_get_next_rmap_item() to then reinitialize the fields in
> cmp_and_merge_page() after remove_rmap_item_from_tree() I guess.
> 

Something like this on top:

diff --git a/mm/ksm.c b/mm/ksm.c
index 0c6bfed280f7..51fd37ee24d6 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -905,6 +905,8 @@ static void remove_node_from_stable_tree(struct ksm_stable_node *stable_node)
                VM_BUG_ON(stable_node->rmap_hlist_len <= 0);
                stable_node->rmap_hlist_len--;
                put_anon_vma(rmap_item->anon_vma);
+               /* Reset pgoff that overlays age-related information. */
+               rmap_item->pgoff = 0;
                rmap_item->address &= PAGE_MASK;
                cond_resched();
        }
@@ -1058,9 +1060,10 @@ static void remove_rmap_item_from_tree(struct ksm_rmap_item *rmap_item)
                stable_node->rmap_hlist_len--;
 
                put_anon_vma(rmap_item->anon_vma);
+               /* Reset pgoff that overlays age-related information. */
+               rmap_item->pgoff = 0;
                rmap_item->head = NULL;
                rmap_item->address &= PAGE_MASK;
-
        } else if (rmap_item->address & UNSTABLE_FLAG) {
                unsigned char age;
                /*
@@ -2465,6 +2468,10 @@ static bool should_skip_rmap_item(struct folio *folio,
        if (folio_test_ksm(folio))
                return false;
 
+       /* There is no age information in stable-tree nodes. */
+       if (rmap_item->address & STABLE_FLAG)
+               return false;
+
        age = rmap_item->age;
        if (age != U8_MAX)
                rmap_item->age++;


But it's all confusing. Because we might temporarily have rmap_item->anon_vma
set on an rmap_entry that does not yet have the STABLE_FLAG flag set through
stable_tree_append().

And then we magically call break_cow() which does a magical

	put_anon_vma(rmap_item->anon_vma);

(this doesn't look correct in once case) ... anyhow.

So we might want to reset the pgoff there as well, OR only store
the pgoff in stable_tree_append() where we actually set STABLE_FLAG.


-- 
Cheers,

David


  reply	other threads:[~2026-04-09 12:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 11:28 [PATCH v3 0/2] KSM: Optimizations for rmap_walk_ksm xu.xin16
2026-02-12 11:29 ` [PATCH v3 1/2] ksm: Initialize the addr only once in rmap_walk_ksm xu.xin16
2026-02-12 11:30 ` [PATCH v3 2/2] ksm: Optimize rmap_walk_ksm by passing a suitable address range xu.xin16
2026-02-12 12:21   ` David Hildenbrand (Arm)
2026-04-05  4:44   ` Hugh Dickins
2026-04-05 21:01     ` Andrew Morton
2026-04-07  9:43       ` Lorenzo Stoakes (Oracle)
2026-04-07 21:21         ` Andrew Morton
2026-04-08  6:29           ` Lorenzo Stoakes
2026-04-06  1:58     ` xu.xin16
2026-04-06  5:35       ` Hugh Dickins
2026-04-07  6:21         ` xu.xin16
2026-04-07  9:36           ` Lorenzo Stoakes (Oracle)
2026-04-08 12:57             ` David Hildenbrand (Arm)
2026-04-09  9:18               ` Lorenzo Stoakes
2026-04-09  9:37                 ` David Hildenbrand (Arm)
2026-04-09  9:41                   ` David Hildenbrand (Arm)
2026-04-09  9:53                     ` Lorenzo Stoakes
2026-04-09  9:56                       ` David Hildenbrand (Arm)
2026-04-09  9:55                     ` David Hildenbrand (Arm)
2026-04-09  9:59                       ` Lorenzo Stoakes
2026-04-09 10:56                       ` 答复: " xu.xin16
2026-04-09 11:59                         ` David Hildenbrand (Arm)
2026-04-09 12:26                           ` David Hildenbrand (Arm) [this message]
2026-04-09 10:06                 ` xu.xin16
2026-04-09 10:09                   ` Lorenzo Stoakes
2026-04-06  9:21     ` David Hildenbrand (arm)
2026-04-06  9:23       ` David Hildenbrand (arm)
2026-04-07  9:39     ` Lorenzo Stoakes (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a2d43c08-984e-4ccf-9faf-abefe0f931b0@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=chengming.zhou@linux.dev \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=michel@lespinasse.org \
    --cc=shr@devkernel.io \
    --cc=wang.yaxin@zte.com.cn \
    --cc=xu.xin16@zte.com.cn \
    --cc=yang.yang29@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox