Re: [RFC 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd_leaves()

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 11/17/25 20:01, Luiz Capitulino wrote:
> On 2025-11-17 12:45, David Hildenbrand (Red Hat) wrote:
>> On 06.11.25 22:28, Luiz Capitulino wrote:
>>> Now that the majority of has_transparent_hugepage() callers have been
>>> converted to pgtable_has_pmd_leaves(), rename has_transparent_hugepage()
>>> to arch_has_pmd_leaves() since that's what the helper checks for.
>>>
>>> arch_has_pmd_leaves() is supposed to be called only by
>>> init_arch_has_pmd_leaves(), except for two exeptions:
>>>
>>> 1. shmem: shmem code runs very early during boot so it can't use
>>>      pgtable_has_pmd_leaves()
>>
>> Can't we just initialize pgtable_has_pmd_leaves() earlier then?
> 
> I can look into doing that. When I worked on this RFC I wondered if
> arch_has_pmd_leaves() (when implemented by the arch) could run so early
> given that some (all?) archs check feature bits so they must be
> available this early as well. But I'll check this, having
> pgtable_has_pmd_leaves() being available as early as possible is
> probably the right thing to do.
> 
>>> 2. hugepage_init(): just a temporary exception, this function will be
>>>      converted in a future commit
>>>
>>> Signed-off-by: Luiz Capitulino <luizcap@redhat.com>
>>> ---
>>
>>
>> [...]
>>
>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>> index e4c5f70b0a01..02a2772ec548 100644
>>> --- a/include/linux/pgtable.h
>>> +++ b/include/linux/pgtable.h
>>> @@ -2026,8 +2026,8 @@ static inline bool pgtable_has_pmd_leaves(void)
>>>    #endif
>>>    #endif
>>> -#ifndef has_transparent_hugepage
>>> -#define has_transparent_hugepage() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE)
>>> +#ifndef arch_has_pmd_leaves
>>> +#define arch_has_pmd_leaves() IS_BUILTIN(CONFIG_TRANSPARENT_HUGEPAGE)
>>>    #endif
>>
>> Ah, so it stays for now only set with CONFIG_TRANSPARENT_HUGEPAGE. I guess that's something to sort out later :)
> 
> I suggested something we could do in this series. Also, I skipped
> commenting on all the cases you spotted as I think they refer to the
> same issue (please, do point out if you think I'm wrong).

Right. If we keep PMD-leave support glue to CONFIG_TRANSPARENT_HUGEPAGE 
in this series, could we also simplify patch #2, to have it reside in 
mm/huge_memory.c ?

Then, it's clearer that it is still glued to CONFIG_TRANSPARENT_HUGEPAGE.

-- 
Cheers

David