mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Luiz Capitulino <luizcap@redhat.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: ryan.roberts@arm.com, akpm@linux-foundation.org,
	lorenzo.stoakes@oracle.com
Subject: Re: [RFC 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd_leaves()
Date: Mon, 17 Nov 2025 14:01:49 -0500	[thread overview]
Message-ID: <65b0c614-e6a9-4535-9d30-bd2be7a72149@redhat.com> (raw)
In-Reply-To: <a64e9422-5474-46cf-9058-73aa29b7906e@kernel.org>

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).


  reply	other threads:[~2025-11-17 19:01 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-06 21:28 [RFC 00/10] mm: thp: always enable mTHP support Luiz Capitulino
2025-11-06 21:28 ` [RFC 01/10] docs: tmpfs: remove implementation detail reference Luiz Capitulino
2025-11-17 17:26   ` David Hildenbrand (Red Hat)
2025-11-06 21:28 ` [RFC 02/10] mm: introduce pgtable_has_pmd_leaves() Luiz Capitulino
2025-11-06 21:28 ` [RFC 03/10] drivers: dax: use pgtable_has_pmd_leaves() Luiz Capitulino
2025-11-17 17:28   ` David Hildenbrand (Red Hat)
2025-11-06 21:28 ` [RFC 04/10] drivers: i915 selftest: " Luiz Capitulino
2025-11-17 17:29   ` David Hildenbrand (Red Hat)
2025-11-17 17:30   ` David Hildenbrand (Red Hat)
2025-11-17 18:55     ` Luiz Capitulino
2025-12-02 10:51       ` David Hildenbrand (Red Hat)
2025-12-03 13:19         ` Luiz Capitulino
2025-11-06 21:28 ` [RFC 05/10] drivers: nvdimm: " Luiz Capitulino
2025-11-17 17:32   ` David Hildenbrand (Red Hat)
2025-11-06 21:28 ` [RFC 06/10] mm: debug_vm_pgtable: " Luiz Capitulino
2025-11-17 17:40   ` David Hildenbrand (Red Hat)
2025-12-03 22:09     ` David Hildenbrand (Red Hat)
2025-11-06 21:28 ` [RFC 07/10] treewide: rename has_transparent_hugepage() to arch_has_pmd_leaves() Luiz Capitulino
2025-11-17 17:45   ` David Hildenbrand (Red Hat)
2025-11-17 19:01     ` Luiz Capitulino [this message]
2025-12-02 10:53       ` David Hildenbrand (Red Hat)
2025-11-06 21:28 ` [RFC 08/10] mm: replace thp_disabled_by_hw() with pgtable_has_pmd_leaves() Luiz Capitulino
2025-11-06 21:28 ` [RFC 09/10] mm: thp: always enable mTHP support Luiz Capitulino
2025-11-17 17:47   ` David Hildenbrand (Red Hat)
2025-11-17 19:14     ` Luiz Capitulino
2025-11-06 21:28 ` [RFC 10/10] mm: thp: x86: cleanup PSE feature bit usage Luiz Capitulino
2025-11-17 17:49   ` David Hildenbrand (Red Hat)
2025-11-17 19:15     ` Luiz Capitulino
2025-12-03 13:58 ` [RFC 00/10] mm: thp: always enable mTHP support Lorenzo Stoakes
2025-12-03 18:41   ` Luiz Capitulino

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=65b0c614-e6a9-4535-9d30-bd2be7a72149@redhat.com \
    --to=luizcap@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ryan.roberts@arm.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

all inboxes | Powered by JetHome®