linux-kernel - Re: [PATCH 1/1] mm: avoid processing mlocked THPs in deferred split shrinker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b30823ea-b987-4284-866b-9e179a2d8eb7@redhat.com>
Date: Mon, 8 Sep 2025 10:33:19 +0200
From: David Hildenbrand <david@...hat.com>
To: Lance Yang <lance.yang@...ux.dev>
Cc: Liam.Howlett@...cle.com, baohua@...nel.org,
 baolin.wang@...ux.alibaba.com, dev.jain@....com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 lorenzo.stoakes@...cle.com, npache@...hat.com, ryan.roberts@....com,
 usamaarif642@...il.com, ziy@...dia.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] mm: avoid processing mlocked THPs in deferred split
 shrinker

>>
>> If I run my reproducer from [1] and mlock() the pages just after
>> allocating them, then I essentially get
>>
>> AnonHugePages:   1048576 kB
>>
>> converted to
>>
>> Anonymous:       1048580 kB
>>
>> Which makes sense (no memory optimized out) as discussed above.
> 
> Yes, my reproducer also shows exactly that. It's clear a lot of work is
> done but no memory is actually optimized out ;)

I'm not really concerned about the scanning overhead. The real harm is 
splitting a THP without any benefit.

-- 
Cheers

David / dhildenb