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

[Luiz Capitulino <luizcap@redhat.com>]

On 2026-05-17 08:03, Lance Yang wrote:
> 
> 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 :)

Yes, I can use that one.