linux-kernel - Re: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <eab4b461-9717-47df-8d56-c303c3f6012d@redhat.com>
Date: Thu, 22 May 2025 14:50:20 +0200
From: David Hildenbrand <david@...hat.com>
To: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>
Cc: Mike Rapoport <rppt@...nel.org>, Pankaj Raghav <p.raghav@...sung.com>,
 Suren Baghdasaryan <surenb@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
 Ryan Roberts <ryan.roberts@....com>, Michal Hocko <mhocko@...e.com>,
 Thomas Gleixner <tglx@...utronix.de>, Nico Pache <npache@...hat.com>,
 Dev Jain <dev.jain@....com>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
 "H . Peter Anvin" <hpa@...or.com>, Zi Yan <ziy@...dia.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Jens Axboe <axboe@...nel.dk>,
 linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 "Darrick J . Wong" <djwong@...nel.org>, gost.dev@...sung.com, hch@....de,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, willy@...radead.org,
 x86@...nel.org, mcgrof@...nel.org
Subject: Re: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE_ALWAYS config option

On 22.05.25 14:34, Pankaj Raghav (Samsung) wrote:
> Hi David,
> 
>>>    config ARCH_WANTS_THP_SWAP
>>>           def_bool n
>>> -config ARCH_WANTS_THP_ZERO_PAGE_ALWAYS
>>> +config ARCH_WANTS_HUGE_ZERO_PAGE_ALWAYS
>>>           def_bool n
>>> +config HUGE_ZERO_PAGE_ALWAYS
>>
>> Likely something like
>>
>> PMD_ZERO_PAGE
>>
>> Will be a lot clearer.
> 
> Sounds much better :)

And maybe something like

"STATIC_PMD_ZERO_PAGE"

would be even clearer.

The other one would be the dynamic one.

> 
>>
>>> +       def_bool y> +       depends on HUGETLB_PAGE &&
>> ARCH_WANTS_HUGE_ZERO_PAGE_ALWAYS
>>
>> I suspect it should then also be independent of HUGETLB_PAGE?
> 
> You are right. So we don't depend on any of these features.
> 
>>
>>> +       help
>>> +         Typically huge_zero_folio, which is a huge page of zeroes, is allocated
>>> +         on demand and deallocated when not in use. This option will always
>>> +         allocate huge_zero_folio for zeroing and it is never deallocated.
>>> +         Not suitable for memory constrained systems.
>>
>> I assume that code then has to live in mm/memory.c ?
> 
> Hmm, then huge_zero_folio should have always been in mm/memory.c to
> begin with?
> 

It's complicated. Only do_huge_pmd_anonymous_page() (and fsdax) really 
uses it, and it may only get mapped into a process under certain 
conditions (related to THP / PMD handling).

> I assume probably this was placed in mm/huge_memory.c because the users
> of this huge_zero_folio has been a part of mm/huge_memory.c?

Yes.

> 
> So IIUC your comment, we should move the huge_zero_page_init() in the
> first patch to mm/memory.c and the existing shrinker code can be a part
> where they already are?

Good question. At least the "static" part can easily be moved over. 
Maybe the dynamic part as well.

Worth trying it out and seeing how it looks :)

-- 
Cheers,

David / dhildenb