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

[Hannes Reinecke <hare@suse.de>]

On 8/11/25 12:43, David Hildenbrand wrote:
> 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)
> 
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