Re: [PATCH v3 0/5] add persistent huge zero folio support

[David Hildenbrand]

On 11.08.25 12:36, Kiryl Shutsemau wrote:
> On Mon, Aug 11, 2025 at 12:21:23PM +0200, David Hildenbrand wrote:
> > On 11.08.25 12:17, Kiryl Shutsemau wrote:
> > > On Mon, Aug 11, 2025 at 11:09:24AM +0100, Lorenzo Stoakes wrote:
> > > > On Mon, Aug 11, 2025 at 11:07:48AM +0100, Kiryl Shutsemau wrote:
> > > > > Well, my worry is that 2M can be a high tax for smaller machines.
> > > > > Compile-time might be cleaner, but it has downsides.
> > > > >
> > > > > It is also not clear if these users actually need physical HZP or virtual
> > > > > is enough. Virtual is cheap.
> > > >
> > > > The kernel config flag (default =N) literally says don't use unless you
> > > > have plenty of memory :)
> > > >
> > > > So this isn't an issue.
> > >
> > > Distros use one-config-fits-all approach. Default N doesn't help
> > > anything.
> >
> > You'd probably want a way to say "use the persistent huge zero folio if you
> > machine has more than X Gigs". That's all reasonable stuff that can be had
> > on top of this series.
>
> We have 'totalram_pages() < (512 << (20 - PAGE_SHIFT))' check in
> hugepage_init(). It can [be abstracted out and] re-used.

I'll note that e.g., RHEL 10 already has a minimum RAM requirement of 2 
GiB. I think for Fedora it's 1 GiB, with the recommendation of having at 
least 2 GiB.

What might be reasonable is having a kconfig option where one (distro) 
can define the minimum RAM size for the persistent huge zero folio, and 
then checking against totalram_pages() during boot.

But again, I think this is something that goes on top of this series. 
(it might also be interesting to allow for disabling the persistent huge 
zero folio through a cmdline option)

--
Cheers,

David / dhildenb