Shmem uses has_transparent_hugepage() to check if PMD-sized pages are
supported, use pgtable_has_pmd_leaves() instead.
Signed-off-by: Luiz Capitulino <luizcap@redhat.com>
---
mm/shmem.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index b329b5302c48..ad5825667b49 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str)
else
return -EINVAL;
- if (!has_transparent_hugepage() &&
+ if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
+ pgtable_has_pmd_leaves()) &&
huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY)
return -EINVAL;
@@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param)
ctx->huge = result.uint_32;
if (ctx->huge != SHMEM_HUGE_NEVER &&
!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
- has_transparent_hugepage()))
+ pgtable_has_pmd_leaves()))
goto unsupported_parameter;
ctx->seen |= SHMEM_SEEN_HUGE;
break;
@@ -5439,7 +5440,7 @@ void __init shmem_init(void)
#endif
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY)
+ if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY)
SHMEM_SB(shm_mnt->mnt_sb)->huge = shmem_huge;
else
shmem_huge = SHMEM_HUGE_NEVER; /* just in case it was patched */
--
2.52.0On 2025/12/16 05:16, Luiz Capitulino wrote: > Shmem uses has_transparent_hugepage() to check if PMD-sized pages are > supported, use pgtable_has_pmd_leaves() instead. > > Signed-off-by: Luiz Capitulino <luizcap@redhat.com> > --- > mm/shmem.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/mm/shmem.c b/mm/shmem.c > index b329b5302c48..ad5825667b49 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str) > else > return -EINVAL; > > - if (!has_transparent_hugepage() && > + if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > + pgtable_has_pmd_leaves()) && > huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY) > return -EINVAL; > > @@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) > ctx->huge = result.uint_32; > if (ctx->huge != SHMEM_HUGE_NEVER && > !(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > - has_transparent_hugepage())) > + pgtable_has_pmd_leaves())) > goto unsupported_parameter; > ctx->seen |= SHMEM_SEEN_HUGE; > break; > @@ -5439,7 +5440,7 @@ void __init shmem_init(void) > #endif > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > - if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY) > + if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY) Using pgtable_has_pmd_leaves() here is a bit confusing because the definition of pgtable_has_pmd_leaves() is: it returns true if the CPU supports PMD-sized pages and false otherwise. However, tmpfs and shmem already support other sizes of large folios, not just PMD-sized large folios. So, for me, using has_transparent_hugepage() to check would be at least clearer (even though it doesn't change the functionality).
On 2025-12-16 02:52, Baolin Wang wrote: > > > On 2025/12/16 05:16, Luiz Capitulino wrote: >> Shmem uses has_transparent_hugepage() to check if PMD-sized pages are >> supported, use pgtable_has_pmd_leaves() instead. >> >> Signed-off-by: Luiz Capitulino <luizcap@redhat.com> >> --- >> mm/shmem.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/mm/shmem.c b/mm/shmem.c >> index b329b5302c48..ad5825667b49 100644 >> --- a/mm/shmem.c >> +++ b/mm/shmem.c >> @@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str) >> else >> return -EINVAL; >> - if (!has_transparent_hugepage() && >> + if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >> + pgtable_has_pmd_leaves()) && >> huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY) >> return -EINVAL; >> @@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) >> ctx->huge = result.uint_32; >> if (ctx->huge != SHMEM_HUGE_NEVER && >> !(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >> - has_transparent_hugepage())) >> + pgtable_has_pmd_leaves())) >> goto unsupported_parameter; >> ctx->seen |= SHMEM_SEEN_HUGE; >> break; >> @@ -5439,7 +5440,7 @@ void __init shmem_init(void) >> #endif >> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >> - if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY) >> + if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY) > > Using pgtable_has_pmd_leaves() here is a bit confusing because the definition of pgtable_has_pmd_leaves() is: it returns true if the CPU supports PMD-sized pages and false otherwise. > > However, tmpfs and shmem already support other sizes of large folios, not just PMD-sized large folios. > > So, for me, using has_transparent_hugepage() to check would be at least clearer (even though it doesn't change the functionality). This is more of a naming issue, correct? Would adding something like thp_has_pmd_support() which expands to: return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && pgtable_has_pmd_leaves(); solve it for you? I suggested it in my RFC, but David advised not to do it. Also, I'm not sure if the comparison with other folio sizes apply, as PUD and PMD sizes are special.
On 2025/12/16 21:47, Luiz Capitulino wrote: > On 2025-12-16 02:52, Baolin Wang wrote: >> >> >> On 2025/12/16 05:16, Luiz Capitulino wrote: >>> Shmem uses has_transparent_hugepage() to check if PMD-sized pages are >>> supported, use pgtable_has_pmd_leaves() instead. >>> >>> Signed-off-by: Luiz Capitulino <luizcap@redhat.com> >>> --- >>> mm/shmem.c | 7 ++++--- >>> 1 file changed, 4 insertions(+), 3 deletions(-) >>> >>> diff --git a/mm/shmem.c b/mm/shmem.c >>> index b329b5302c48..ad5825667b49 100644 >>> --- a/mm/shmem.c >>> +++ b/mm/shmem.c >>> @@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str) >>> else >>> return -EINVAL; >>> - if (!has_transparent_hugepage() && >>> + if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >>> + pgtable_has_pmd_leaves()) && >>> huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY) >>> return -EINVAL; >>> @@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context >>> *fc, struct fs_parameter *param) >>> ctx->huge = result.uint_32; >>> if (ctx->huge != SHMEM_HUGE_NEVER && >>> !(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >>> - has_transparent_hugepage())) >>> + pgtable_has_pmd_leaves())) >>> goto unsupported_parameter; >>> ctx->seen |= SHMEM_SEEN_HUGE; >>> break; >>> @@ -5439,7 +5440,7 @@ void __init shmem_init(void) >>> #endif >>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >>> - if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY) >>> + if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY) >> >> Using pgtable_has_pmd_leaves() here is a bit confusing because the >> definition of pgtable_has_pmd_leaves() is: it returns true if the CPU >> supports PMD-sized pages and false otherwise. >> >> However, tmpfs and shmem already support other sizes of large folios, >> not just PMD-sized large folios. >> >> So, for me, using has_transparent_hugepage() to check would be at >> least clearer (even though it doesn't change the functionality). > > This is more of a naming issue, correct? Yes. > Would adding something like thp_has_pmd_support() which expands to: > > return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && > pgtable_has_pmd_leaves(); > > solve it for you? I suggested it in my RFC, but David advised not to do it. I agree with David. The thp_has_pmd_support() is not helpful too. What I mean is that the term 'pmd' shouldn't be used here. PMD-sized large folios aren't any more special than others. shmem also supports mTHP, and a better approach might be what you did in patch 10: even if PMD-sized pages are not supported on an architecture, shmem can still use other sizes of mTHP. > Also, I'm not sure if the comparison with other folio sizes apply, as > PUD and PMD sizes are special.
On 2025-12-16 21:03, Baolin Wang wrote: > > > On 2025/12/16 21:47, Luiz Capitulino wrote: >> On 2025-12-16 02:52, Baolin Wang wrote: >>> >>> >>> On 2025/12/16 05:16, Luiz Capitulino wrote: >>>> Shmem uses has_transparent_hugepage() to check if PMD-sized pages are >>>> supported, use pgtable_has_pmd_leaves() instead. >>>> >>>> Signed-off-by: Luiz Capitulino <luizcap@redhat.com> >>>> --- >>>> mm/shmem.c | 7 ++++--- >>>> 1 file changed, 4 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/mm/shmem.c b/mm/shmem.c >>>> index b329b5302c48..ad5825667b49 100644 >>>> --- a/mm/shmem.c >>>> +++ b/mm/shmem.c >>>> @@ -689,7 +689,8 @@ static int shmem_parse_huge(const char *str) >>>> else >>>> return -EINVAL; >>>> - if (!has_transparent_hugepage() && >>>> + if (!(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >>>> + pgtable_has_pmd_leaves()) && >>>> huge != SHMEM_HUGE_NEVER && huge != SHMEM_HUGE_DENY) >>>> return -EINVAL; >>>> @@ -4655,7 +4656,7 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) >>>> ctx->huge = result.uint_32; >>>> if (ctx->huge != SHMEM_HUGE_NEVER && >>>> !(IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && >>>> - has_transparent_hugepage())) >>>> + pgtable_has_pmd_leaves())) >>>> goto unsupported_parameter; >>>> ctx->seen |= SHMEM_SEEN_HUGE; >>>> break; >>>> @@ -5439,7 +5440,7 @@ void __init shmem_init(void) >>>> #endif >>>> #ifdef CONFIG_TRANSPARENT_HUGEPAGE >>>> - if (has_transparent_hugepage() && shmem_huge > SHMEM_HUGE_DENY) >>>> + if (pgtable_has_pmd_leaves() && shmem_huge > SHMEM_HUGE_DENY) >>> >>> Using pgtable_has_pmd_leaves() here is a bit confusing because the definition of pgtable_has_pmd_leaves() is: it returns true if the CPU supports PMD-sized pages and false otherwise. >>> >>> However, tmpfs and shmem already support other sizes of large folios, not just PMD-sized large folios. >>> >>> So, for me, using has_transparent_hugepage() to check would be at least clearer (even though it doesn't change the functionality). >> >> This is more of a naming issue, correct? > > Yes. > >> Would adding something like thp_has_pmd_support() which expands to: >> >> return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && pgtable_has_pmd_leaves(); >> >> solve it for you? I suggested it in my RFC, but David advised not to do it. > > I agree with David. The thp_has_pmd_support() is not helpful too. What I mean is that the term 'pmd' shouldn't be used here. PMD-sized large folios aren't any more special than others. > > shmem also supports mTHP, and a better approach might be what you did in patch 10: even if PMD-sized pages are not supported on an architecture, shmem can still use other sizes of mTHP. Oh, I get watch you mean now. I'll have to dig a little deeper into the shmem code but I'll give your suggestion a try. Thanks for your feedback. > >> Also, I'm not sure if the comparison with other folio sizes apply, as >> PUD and PMD sizes are special. >
© 2016 - 2025 Red Hat, Inc.