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

Message-ID: <b3ceg4gdg5exbugyarudabfuaowvqfqgrzo62hoexxhvvfwjs7@4dbrig7wm7ds>
Date: Thu, 22 May 2025 15:34:17 +0200
From: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>
To: David Hildenbrand <david@...hat.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 Thu, May 22, 2025 at 02:50:20PM +0200, David Hildenbrand wrote:
> 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.

Got it.
So if I understand correctly, we are going to have two huge zero pages,
- one that is always allocated statically.
- the existing dynamic will still be there for the existing users.

> 
> > 
> > > 
> > > > +       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).
> 
Got it.
> > 
> > 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 :)

Challenge accepted ;) Thanks for the comments David.

--
Pankaj