Re: [Regerssion] [KSM] KSM CPU overhead in 6.16+ kernel compared to <=6.15 versions ("folio_walk_start" kernel object overhead)

[David Hildenbrand]

On 13.10.25 21:58, David Hildenbrand wrote:
> On 13.10.25 21:54, craftfever wrote:
> > Unfortunately, yes I can reproduce it. And I thought that lockups does
> > not happen anymore, but I was wrong, I booted today with 6.17.2 updated
> > and KSM enabled and whole situation is back. But, it only happens, when
> > scanning pages corresponding to a process with huge VM size, like
> > Chromium with 1TB of virtual memory. The rest is alright. It's look
> > like, that the folio_walk_start called with much higher frequency, than
> > in 6.12-6.15 versions. in that version page scanning of huge VM size
> > processes is pretty fast and flawless) Right now, when Chromium is
> > running, I expecting constant 42% folio_walk_start and 15%
> > ksm_scan_thread on 6.17.2 kernel (contrary to 1% folio_walk_start and
> > even less ksm_scan_thread in 6.12-6.15). I must admin that whole system
> > is not freezing, just Chromium with high CPU usage from ksmd and kernel.
>
> What about 6.16?

What you replied to in private:

Just compared stock kernels (6.16.8 and 6.17.2) and must admit that the
behavior pretty same, same lockup, when just starting Chromium and same
kernel objects and ksmd overhead. No difference. (Approx 20-32% of
"folio_walk_start" and 10% ksm_scan_thread at this time on both kernels)


IIUC, 6.16.8 dos not contain a backport of Lorenzos fix, so we can rule that one out I think.

There is another VMA merging related one in 6.16:

commit 879bca0a2c4f40b08d09a95a2a0c3c6513060b5c
Author: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Date:   Tue Apr 8 10:29:31 2025 +0100

    mm/vma: fix incorrectly disallowed anonymous VMA merges
    
    Patch series "fix incorrectly disallowed anonymous VMA merges", v2.
    
    It appears that we have been incorrectly rejecting merge cases for 15
    years, apparently by mistake.
    
    Imagine a range of anonymous mapped momemory divided into two VMAs like
    this, with incompatible protection bits:
    
Could you try reverting 879bca0a2c4f40b08d09a95a2a0c3c6513060b5c on top of 6.16 and
see if the problem goes away?

Meanwhile I'll try using an ordinary pagewalk that covers a larger area
instead of a foliowalk that walks each address.

--
Cheers

David / dhildenb