Re: [PATCH v3 02/10] mm: introduce pgtable_has_pmd_leaves()

[Luiz Capitulino]

On 2026-04-10 04:19, Lance Yang wrote:
> On Wed, Apr 08, 2026 at 04:22:57PM -0400, Luiz Capitulino wrote:
> > Currently, we have two helpers that check for PMD-sized pages but have
> > different names and slightly different semantics:
> >
> > - has_transparent_hugepage(): the name suggests it checks if THP is
> >   enabled, but when CONFIG_TRANSPARENT_HUGEPAGE=y and the architecture
> >   implements this helper, it actually checks if the CPU supports
> >   PMD-sized pages
> >
> > - thp_disabled_by_hw(): the name suggests it checks if THP is disabled
> >   by the hardware, but it just returns a cached value acquired with
> >   has_transparent_hugepage(). This helper is used in fast paths
> >
> > This commit introduces a new helper called pgtable_has_pmd_leaves()
> > which is intended to replace both has_transparent_hugepage() and
> > thp_disabled_by_hw(). pgtable_has_pmd_leaves() has very clear semantics:
> > it returns true if the CPU supports PMD-sized pages and false otherwise.
> > It always returns a cached value, so it can be used in fast paths.
> >
> > The new helper requires an initialization step which is performed by
> > init_arch_has_pmd_leaves(). We call init_arch_has_pmd_leaves() early
> > during boot in start_kernel() right after parse_early_param() but before
> > parse_args(). This allows early_param() handlers to change CPU flags if
> > needed (eg. parse_memopt() in x86-32) while also allowing users to use
> > the API from __setup() handlers.
> >
> > The next commits will convert users of both has_transparent_hugepage()
> > and thp_disabled_by_hw() to pgtable_has_pmd_leaves().
> >
> > Signed-off-by: Luiz Capitulino <luizcap@xxxxxxxxxx>
> > ---
> > include/linux/pgtable.h | 15 +++++++++++++++
> > init/main.c             |  1 +
> > mm/memory.c             |  8 ++++++++
> > 3 files changed, 24 insertions(+)
> >
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index a50df42a893f..c4c5282f795c 100644
> > --- a/include/linux/pgtable.h
> > +++ b/include/linux/pgtable.h
> > @@ -2192,6 +2192,21 @@ static inline const char *pgtable_level_to_str(enum pgtable_level level)
> > 	}
> > }
> >
> > +#ifdef CONFIG_MMU
> > +extern bool __arch_has_pmd_leaves;
> > +static inline bool pgtable_has_pmd_leaves(void)
> > +{
> > +	return __arch_has_pmd_leaves;
> > +}
> > +void __init init_arch_has_pmd_leaves(void);
> > +#else
> > +static inline bool pgtable_has_pmd_leaves(void)
> > +{
> > +	return false;
> > +}
> > +static inline void __init init_arch_has_pmd_leaves(void) { }
> > +#endif
> > +
> > #endif /* !__ASSEMBLY__ */
> >
> > #if !defined(MAX_POSSIBLE_PHYSMEM_BITS) && !defined(CONFIG_64BIT)
> > diff --git a/init/main.c b/init/main.c
> > index 1cb395dd94e4..07f2ddbf9677 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1044,6 +1044,7 @@ void start_kernel(void)
> > 	print_kernel_cmdline(saved_command_line);
> > 	/* parameters may set static keys */
> > 	parse_early_param();
> > +	init_arch_has_pmd_leaves();
>
> One more thought here: I don't see why we need boot-time caching.
>
> has_transparent_hugepage() does *not* look expensive on the common
> archs. On x86, it is just a CPU feature check. MIPS is different, yes,
> only the first call there is more involved ...

The caching is not being introduced by this series. thp_disabled_by_hw()
(which is used in hot paths) is checking a cached value too and this
cached value is also set at boot-time by hugepage_init(). So, we keep
the same behavior while extending the use of the cached value in the API
(which makes sense for consistency).

> But if we *really* want caching, couldn't we just do it lazily instead
> of adding another early boot init step?
>
> Something like:
>
> bool pgtable_has_pmd_leaves(void)
> {
> 	static int __arch_has_pmd_leaves = -1;
>
> 	if (READ_ONCE(__arch_has_pmd_leaves) < 0)
> 		WRITE_ONCE(__arch_has_pmd_leaves, has_transparent_hugepage());
>
> 	return READ_ONCE(__arch_has_pmd_leaves);
> }
>
> That would avoid depending on parse_early_param() / parse_args()
> ordering, and it seems much simpler too :)
>
> The boot-time init step looks a bit shaky to me ...

I understand that caching on first access as you suggest above is an
alternative way of doing this, but having to properly order
initialization is very common in start_kernel(). So, unless we identify
a case where the ordering is tricky or undoable, I don't see an issue
with it. Also, note that this ordering exists today but it's implicity:
thp_disabled_by_hw() can only be called after hugepage_init() runs.

In terms of simplicity, look at how the resulting code (using an
untested version of your static key suggestion) looks in comparison to
caching at first use:

DEFINE_STATIC_KEY_TRUE(__arch_has_pmd_leaves_key);

static inline bool pgtable_has_pmd_leaves(void)
{
	return static_branch_likely(&__arch_has_pmd_leaves_key);
}

void __init init_arch_has_pmd_leaves(void)
{
	if (!arch_has_pmd_leaves())
		static_branch_disable(&__arch_has_pmd_leaves_key);
}