Re: [PATCH 2/2] kpageflags: fix wrong KPF_THP on non-pmd-mappable compound pages

[Zi Yan]

On Wed Jun 26, 2024 at 7:07 AM EDT, Ryan Roberts wrote:
> On 26/06/2024 04:06, Zi Yan wrote:
> > On Tue Jun 25, 2024 at 10:49 PM EDT, ran xiaokai wrote:
> >> From: Ran Xiaokai <ran.xiaokai@xxxxxxxxxx>
> >>
> >> KPF_COMPOUND_HEAD and KPF_COMPOUND_TAIL are set on "common" compound
> >> pages, which means of any order, but KPF_THP should only be set
> >> when the folio is a 2M pmd mappable THP. 
>
> Why should KPF_THP only be set on 2M THP? What problem does it cause as it is
> currently configured?
>
> I would argue that mTHP is still THP so should still have the flag. And since
> these smaller mTHP sizes are disabled by default, only mTHP-aware user space
> will be enabling them, so I'll naively state that it should not cause compat
> issues as is.
>
> Also, the script at tools/mm/thpmaps relies on KPF_THP being set for all mTHP
> sizes to function correctly. So that would need to be reworked if making this
> change.

+ more folks working on mTHP

I agree that mTHP is still THP, but we might want different
stats/counters for it, since people might want to keep the old THP counters
consistent. See recent commits on adding mTHP counters:
ec33687c6749 ("mm: add per-order mTHP anon_fault_alloc and anon_fault_fallback
counters"), 1f97fd042f38 ("mm: shmem: add mTHP counters for anonymous shmem")

and changes to make THP counter to only count PMD THP:
835c3a25aa37 ("mm: huge_memory: add the missing folio_test_pmd_mappable() for
THP split statistics")

In this case, I wonder if we want a new KPF_MTHP bit for mTHP and some
adjustment on tools/mm/thpmaps.


-- 
Best Regards,
Yan, Zi

Attachment: signature.asc
Description: PGP signature