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

[Lance Yang]

On Wed, May 13, 2026 at 09:52:05PM -0400, Luiz Capitulino wrote:
[...]
>>>   
>>>   #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()?

Indeed. If nobody needs pgtable_has_pmd_leaves() that early, it is
cleaner to put it in MM init code :)

>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.

Or what about pgtable_leaf_support_init()? It says what this init is for,
setting up the cached leaf-support check. Today that only means PMD
leaves, but the name still works if we add PUD leaves later :)

Cheers, Lance