Re: [PATCH v4] ksm: use range-walk function to jump over holes in scan_get_next_rmap_item

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 22 Oct 2025 12:30:59 -0300 Pedro Demarchi Gomes <pedrodemargomes@gmail.com> wrote:

> Currently, scan_get_next_rmap_item() walks every page address in a VMA
> to locate mergeable pages. This becomes highly inefficient when scanning
> large virtual memory areas that contain mostly unmapped regions.
> 
> This patch replaces the per-address lookup with a range walk using
> walk_page_range(). The range walker allows KSM to skip over entire
> unmapped holes in a VMA, avoiding unnecessary lookups.
> This problem was previously discussed in [1].
> 
> [1] https://lore.kernel.org/linux-mm/423de7a3-1c62-4e72-8e79-19a6413e420c@redhat.com/
> 

Thanks.  It would be helpful of the changelog were to tell people how
significant this change is for our users.

> Reported-by: craftfever <craftfever@airmail.cc>
> Closes: https://lkml.kernel.org/r/020cf8de6e773bb78ba7614ef250129f11a63781@murena.io

Buried in here is a claim that large amount of CPU are being used, but
nothing quantitative.

So is there something we can tell people who are looking at this patch
in Feb 2026 and wondering "hm, should I add that to our kernel"?

> Suggested-by: David Hildenbrand <david@redhat.com>
> Co-developed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Fixes: 31dbd01f3143 ("ksm: Kernel SamePage Merging")

If the observed runtime problem is bad enough then a cc:stable might be
justified.  But a description of that observed runtime behavior would
be needed for that, please.