From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Lance Yang <lance.yang@linux.dev>, luizcap@redhat.com
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
baolin.wang@linux.alibaba.com, ryan.roberts@arm.com,
akpm@linux-foundation.org, ljs@kernel.org, ziy@nvidia.com,
Liam.Howlett@oracle.com, npache@redhat.com, dev.jain@arm.com,
baohua@kernel.org
Subject: Re: [PATCH v3 02/10] mm: introduce pgtable_has_pmd_leaves()
Date: Fri, 17 Apr 2026 11:57:54 +0200 [thread overview]
Message-ID: <8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org> (raw)
In-Reply-To: <20260410081938.51302-1-lance.yang@linux.dev>
On 4/10/26 10: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@redhat.com>
>> ---
>> 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 ...
>
> 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);
Would look easier when just using two booleans: "has_pmd_leaves" and
"probed".
I do like static keys, though. And wonder whether just putting that into
hugepage_init() would be sufficient?
--
Cheers,
David
next prev parent reply other threads:[~2026-04-17 9:58 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 20:22 [PATCH v3 00/10] mm: thp: always enable mTHP support Luiz Capitulino
2026-04-08 20:22 ` [PATCH v3 01/10] docs: tmpfs: remove implementation detail reference Luiz Capitulino
2026-04-09 15:11 ` Zi Yan
2026-04-10 16:00 ` Lance Yang
2026-04-08 20:22 ` [PATCH v3 02/10] mm: introduce pgtable_has_pmd_leaves() Luiz Capitulino
2026-04-09 12:26 ` Lance Yang
2026-04-09 18:22 ` Luiz Capitulino
2026-04-10 8:19 ` Lance Yang
2026-04-13 15:24 ` Luiz Capitulino
2026-04-13 15:45 ` Lance Yang
2026-04-17 9:57 ` David Hildenbrand (Arm) [this message]
2026-04-17 12:57 ` Luiz Capitulino
2026-04-08 20:22 ` [PATCH v3 03/10] drivers: dax: use pgtable_has_pmd_leaves() Luiz Capitulino
2026-04-08 20:22 ` [PATCH v3 04/10] drivers: nvdimm: " Luiz Capitulino
2026-04-09 15:21 ` Zi Yan
2026-04-09 18:51 ` Luiz Capitulino
2026-04-08 20:23 ` [PATCH v3 05/10] mm: debug_vm_pgtable: " Luiz Capitulino
2026-04-09 15:25 ` Zi Yan
2026-04-10 16:09 ` Lance Yang
2026-04-08 20:23 ` [PATCH v3 06/10] mm: shmem: drop has_transparent_hugepage() usage Luiz Capitulino
2026-04-09 15:26 ` Zi Yan
2026-04-10 15:59 ` Lance Yang
2026-04-11 4:00 ` Lance Yang
2026-04-11 6:56 ` Baolin Wang
2026-04-08 20:23 ` [PATCH v3 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd_leaves() Luiz Capitulino
2026-04-09 15:41 ` Zi Yan
2026-04-09 19:43 ` Luiz Capitulino
2026-04-13 15:32 ` Luiz Capitulino
2026-04-13 15:34 ` Zi Yan
2026-04-08 20:23 ` [PATCH v3 08/10] mm: replace thp_disabled_by_hw() with pgtable_has_pmd_leaves() Luiz Capitulino
2026-04-09 15:43 ` Zi Yan
2026-04-11 7:01 ` Baolin Wang
2026-04-12 14:44 ` Lance Yang
2026-04-08 20:23 ` [PATCH v3 09/10] mm: thp: always enable mTHP support Luiz Capitulino
2026-04-09 15:55 ` Zi Yan
2026-04-09 20:07 ` Luiz Capitulino
2026-04-09 20:10 ` Zi Yan
2026-04-09 21:19 ` Luiz Capitulino
2026-04-11 7:22 ` Baolin Wang
2026-04-13 15:39 ` Luiz Capitulino
2026-04-08 20:23 ` [PATCH v3 10/10] mm: thp: x86: cleanup PSE feature bit usage Luiz Capitulino
2026-04-09 15:57 ` Zi Yan
2026-04-09 20:10 ` Dave Hansen
2026-04-09 21:24 ` Luiz Capitulino
2026-04-09 8:29 ` [PATCH v3 00/10] mm: thp: always enable mTHP support Lance Yang
2026-04-09 8:36 ` Lorenzo Stoakes
2026-04-09 18:18 ` Luiz Capitulino
2026-04-09 12:35 ` Lance Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a0b6d67-121a-4ac8-a74b-737d52d8b7ac@kernel.org \
--to=david@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luizcap@redhat.com \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox