Re: [RFC 2/3] mm: add STATIC_PMD_ZERO_PAGE config option

[Dave Hansen <dave.hansen@intel.com>]

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 055204dc211d..96f99b4f96ea 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -152,6 +152,7 @@ config X86
>  	select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP	if X86_64
>  	select ARCH_WANT_HUGETLB_VMEMMAP_PREINIT if X86_64
>  	select ARCH_WANTS_THP_SWAP		if X86_64
> +	select ARCH_WANTS_STATIC_PMD_ZERO_PAGE if X86_64

I don't think this should be the default. There are lots of little
x86_64 VMs sitting around and 2MB might be significant to them.

> +config ARCH_WANTS_STATIC_PMD_ZERO_PAGE
> +	bool
> +
> +config STATIC_PMD_ZERO_PAGE
> +	def_bool y
> +	depends on ARCH_WANTS_STATIC_PMD_ZERO_PAGE
> +	help
> +	  Typically huge_zero_folio, which is a PMD 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.

"Static" seems like a weird term to use for this. I was really expecting
to see a 2MB object that gets allocated in .bss or something rather than
a dynamically allocated page that's just never freed.

>  menuconfig TRANSPARENT_HUGEPAGE
>  	bool "Transparent Hugepage Support"
>  	depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT
> diff --git a/mm/memory.c b/mm/memory.c
> index 11edc4d66e74..ab8c16d04307 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -203,9 +203,17 @@ static void put_huge_zero_page(void)
>  	BUG_ON(atomic_dec_and_test(&huge_zero_refcount));
>  }
>  
> +/*
> + * If STATIC_PMD_ZERO_PAGE is enabled, @mm can be NULL, i.e, the huge_zero_folio
> + * is not associated with any mm_struct.
> +*/

I get that callers have to handle failure. But isn't this pretty nasty
for mm==NULL callers to be *guaranteed* to fail? They'll generate code
for the success case that will never even run.