Hi David, > > 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. Sounds much better :) > > > + def_bool y> + depends on HUGETLB_PAGE && > ARCH_WANTS_HUGE_ZERO_PAGE_ALWAYS > > I suspect it should then also be independent of HUGETLB_PAGE? You are right. So we don't depend on any of these features. > > > + 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 ? Hmm, then huge_zero_folio should have always been in mm/memory.c to begin with? I assume probably this was placed in mm/huge_memory.c because the users of this huge_zero_folio has been a part of mm/huge_memory.c? So IIUC your comment, we should move the huge_zero_page_init() in the first patch to mm/memory.c and the existing shrinker code can be a part where they already are? -- Pankaj
