Re: [PATCH v3 02/10] mm: introduce pgtable_has_pmd_leaves()
From: Luiz Capitulino
Date: Fri Apr 17 2026 - 08:57:47 EST
On 2026-04-17 05:57, David Hildenbrand (Arm) wrote:
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@xxxxxxxxxx>
---
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?
Do you mean the static key initialization? I think it's sufficient today,
but we'd be tying the new API to THP and the initialization ordering still
occurs although it's indirect.