On 8/11/25 12:43, David Hildenbrand wrote:

On 11.08.25 12:36, Kiryl Shutsemau wrote:

quoted

On Mon, Aug 11, 2025 at 12:21:23PM +0200, David Hildenbrand wrote:

quoted

On 11.08.25 12:17, Kiryl Shutsemau wrote:

quoted

On Mon, Aug 11, 2025 at 11:09:24AM +0100, Lorenzo Stoakes wrote:

quoted

On Mon, Aug 11, 2025 at 11:07:48AM +0100, Kiryl Shutsemau wrote:

quoted

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)

Please make this a kernel config option and don't rely on heuristics.
They have the nasty habit of doing exactly the wrong thing at places
where you really don't expect them to.
(Consider SoCs with a large CMA area for video grabbing or similar stuff
and very little main memory ...)
A kernel option will give distros and/or admins the flexibility they
need without having to rebuild the kernel and also not having to
worry about heuristics going wrong.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich