Re: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE_ALWAYS config option

[David Hildenbrand <david@redhat.com>]

On 22.05.25 14:00, Pankaj Raghav (Samsung) wrote:
> Hi Mike,
> 
>>> Add a config option THP_HUGE_ZERO_PAGE_ALWAYS that will always allocate
>>> the huge_zero_folio, and it will never be freed. This makes using the
>>> huge_zero_folio without having to pass any mm struct and a call to put_folio
>>> in the destructor.
>>
>> I don't think this config option should be tied to THP. It's perfectly
>> sensible to have a configuration with HUGETLB and without THP.
>>   
> 
> Hmm, that makes sense. You mean something like this (untested):
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 2e1527580746..d447a9b9eb7d 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -151,8 +151,8 @@ config X86
>          select ARCH_WANT_OPTIMIZE_DAX_VMEMMAP   if X86_64
>          select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP       if X86_64
>          select ARCH_WANT_HUGETLB_VMEMMAP_PREINIT if X86_64
> +       select ARCH_WANTS_HUGE_ZERO_PAGE_ALWAYS if X86_64
>          select ARCH_WANTS_THP_SWAP              if X86_64
> -       select ARCH_WANTS_THP_ZERO_PAGE_ALWAYS  if X86_64
>          select ARCH_HAS_PARANOID_L1D_FLUSH
>          select BUILDTIME_TABLE_SORT
>          select CLKEVT_I8253
> diff --git a/mm/Kconfig b/mm/Kconfig
> index a2994e7d55ba..83a5b95a2286 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -823,9 +823,19 @@ config ARCH_WANT_GENERAL_HUGETLB
>   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.

 > +       def_bool y> +       depends on HUGETLB_PAGE && 
ARCH_WANTS_HUGE_ZERO_PAGE_ALWAYS

I suspect it should then also be independent of HUGETLB_PAGE?

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


-- 
Cheers,

David / dhildenb