Re: [PATCH v4 2/9] mm: introduce pgtable_has_pmd_leaves()

[Luiz Capitulino <luizcap@redhat.com>]

On 2026-05-13 11:30, David Hildenbrand (Arm) wrote:
> On 5/1/26 21:18, 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@redhat.com>
>> ---
>>   include/linux/pgtable.h | 15 +++++++++++++++
>>   init/main.c             |  1 +
>>   mm/memory.c             |  9 +++++++++
>>   3 files changed, 25 insertions(+)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index cdd68ed3ae1a..b365be3516bf 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -2243,6 +2243,21 @@ static inline const char *pgtable_level_to_str(enum pgtable_level level)
>>   	}
>>   }
>>   
>> +#ifdef CONFIG_MMU
>> +DECLARE_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);
>> +#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 96f93bb06c49..eea7c5bdddf7 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -1053,6 +1053,7 @@ void start_kernel(void)
>>   	print_kernel_cmdline(saved_command_line);
>>   	/* parameters may set static keys */
>>   	parse_early_param();
>> +	init_arch_has_pmd_leaves();
> 
> Can't we do this a bit later from some mm code?
> 
> This feels like something that can just go somewhere into mm_core_init()?

Yes, this can be done. My intent in calling it as early as possible was
to allow callers to use the API from __setup() handlers if needed, but
since we don't have this case in the code today we can put it in
mm_core_init() for now.

> There, we should probably call this something like XXX_init(), and prepare it
> from detecting support for PUD leaves as well.
> 
> Maybe just
> 
> pgtable_init() ?

What about pgtable_api_init()? I'm afraid that pgtable_init() might be
confused with code doing real page table initialization.