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: <625s5hffr3iz35uv4hts4sxpprwwuxxpbsmbvasy24cthlsj6x@tg2zqm6v2wqm>
Date: Thu, 22 May 2025 14:34:43 +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

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 :)

> 
> > +       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?

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?

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?

--
Pankaj