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
next prev parent 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