From: craftfever <craftfever@airmail.cc>
To: Andrew Morton <akpm@linux-foundation.org>,
Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
Cc: David Hildenbrand <david@redhat.com>,
Xu Xin <xu.xin16@zte.com.cn>,
Chengming Zhou <chengming.zhou@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ksm: use range-walk function to jump over holes in scan_get_next_rmap_item
Date: Thu, 16 Oct 2025 21:33:00 +0000 [thread overview]
Message-ID: <81fec1a5-1fac-4a50-871a-eaa0f2a2bcb3@airmail.cc> (raw)
In-Reply-To: <20251016140735.d7d4c282f0fbf22954a4b4ee@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 15 Oct 2025 22:22:36 -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].
>>
>> ...
>>
>> Reported-by: craftfever <craftfever@airmail.cc>
>> Closes: https://lkml.kernel.org/r/020cf8de6e773bb78ba7614ef250129f11a63781@murena.io
>> Suggested-by: David Hildenbrand <david@redhat.com>
>> Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
>
> Is Fixes: b1d3e9bbccb4 ("mm/ksm: convert scan_get_next_rmap_item() from
> follow_page() to folio_walk") appropriate?
>
> The problem which is being addressed seems pretty serious. What do
> people think about proposing a -stable backport of this fix?
>
> It would be better if this changelog were to describe the user-visible
> effects of the problem. A copy-n-paste from
> https://bugzilla.kernel.org/show_bug.cgi?id=220599 would suffice.
I must admit, that with this particular fix with scanning only mapped
pages with actual data, effectiveness of KSM even better according to
stats, and CPU consumption even smaller tan was in 6.12-6.15 kernels, so
I think it doesn't necessary to revert that 6.12 folio_walk commit,
applying to master tree and backporting this topic fix into stable
branch is sufficient.
next prev parent reply other threads:[~2025-10-16 21:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 1:22 [PATCH v3] ksm: use range-walk function to jump over holes in scan_get_next_rmap_item Pedro Demarchi Gomes
2025-10-16 19:35 ` craftfever
2025-10-16 21:07 ` Andrew Morton
2025-10-16 21:33 ` craftfever [this message]
2025-10-16 21:54 ` craftfever
2025-10-20 9:42 ` David Hildenbrand
2025-10-17 15:44 ` David Hildenbrand
2025-10-17 22:23 ` David Hildenbrand
2025-10-18 7:30 ` craftfever
2025-10-20 9:38 ` David Hildenbrand
2025-10-21 3:00 ` Pedro Demarchi Gomes
2025-10-21 15:25 ` David Hildenbrand
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=81fec1a5-1fac-4a50-871a-eaa0f2a2bcb3@airmail.cc \
--to=craftfever@airmail.cc \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pedrodemargomes@gmail.com \
--cc=xu.xin16@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