On 22.05.25 14:34, Pankaj Raghav (Samsung) wrote:
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 :)
And maybe something like
"STATIC_PMD_ZERO_PAGE"
would be even clearer.
The other one would be the dynamic one.
+ 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?
It's complicated. Only do_huge_pmd_anonymous_page() (and fsdax) really
uses it, and it may only get mapped into a process under certain
conditions (related to THP / PMD handling).
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?
Yes.
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?
Good question. At least the "static" part can easily be moved over.
Maybe the dynamic part as well.
Worth trying it out and seeing how it looks :)
--
Cheers,
David / dhildenb
