> 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.
