linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <chleroy@kernel.org>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Sourabh Jain <sourabhjain@linux.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Donet Tom <donettom@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH v1] mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb
Date: Thu, 13 Nov 2025 19:44:31 +0100	[thread overview]
Message-ID: <027b6ac9-836d-4f89-a819-e24d487f9c8e@kernel.org> (raw)
In-Reply-To: <3fa6d496-b9de-4b66-a7db-247eebec92ca@kernel.org>



Le 13/11/2025 à 16:21, David Hildenbrand (Red Hat) a écrit :
> On 13.11.25 14:01, Lorenzo Stoakes wrote:
> 
> [...]
> 
>>> @@ -137,6 +137,7 @@ config PPC
>>>       select ARCH_HAS_DMA_OPS            if PPC64
>>>       select ARCH_HAS_FORTIFY_SOURCE
>>>       select ARCH_HAS_GCOV_PROFILE_ALL
>>> +    select ARCH_HAS_GIGANTIC_PAGE        if ARCH_SUPPORTS_HUGETLBFS
>>
>> Given we know the architecture can support it (presumably all powerpc
>> arches or all that can support hugetlbfs anyway?), this seems reasonable.
> 
> powerpc allows for quite some different configs, so I assume there are 
> some configs that don't allow ARCH_SUPPORTS_HUGETLBFS.

Yes indeed. For instance the powerpc 603 and 604 have no huge pages.

> 
> [...]
> 
>>>   /*
>>>    * There is no real limit on the folio size. We limit them to the 
>>> maximum we
>>> - * currently expect (e.g., hugetlb, dax).
>>> + * currently expect: with hugetlb, we expect no folios larger than 
>>> 16 GiB.
>>
>> Maybe worth saying 'see CONFIG_HAVE_GIGANTIC_FOLIOS definition' or 
>> something?
> 
> To me that's implied from the initial ifdef. But not strong opinion 
> about spelling that out.
> 
>>
>>> + */
>>> +#define MAX_FOLIO_ORDER        get_order(SZ_16G)
>>
>> Hmm, is the base page size somehow runtime adjustable on powerpc? Why 
>> isn't
>> PUD_ORDER good enough here?
> 
> We tried P4D_ORDER but even that doesn't work. I think we effectively 
> end up with cont-pmd/cont-PUD mappings (or even cont-p4d, I am not 100% 
> sure because the folding code complicates that).
> 
> See powerpcs variant of huge_pte_alloc() where we have stuff like
> 
> p4d = p4d_offset(pgd_offset(mm, addr), addr);
> if (!mm_pud_folded(mm) && sz >= P4D_SIZE)
>      return (pte_t *)p4d;
> 
> As soon as we go to things like P4D_ORDER we're suddenly in the range of 
> 512 GiB on x86 etc, so that's also not what we want as an easy fix. (and 
> it didn't work)
> 

On 32 bits there are only PGDIR et Page Table,

PGDIR_SHIFT = P4D_SHIFT = PUD_SHIFT = PMD_SHIFT

For instance on powerpc 8xx,
PGDIR_SIZE is 4M
Largest hugepage is 8M.

So even PGDIR_ORDER isn't enough.

Christophe


  reply	other threads:[~2025-11-13 18:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 14:56 David Hildenbrand (Red Hat)
2025-11-13 13:01 ` Lorenzo Stoakes
2025-11-13 15:21   ` David Hildenbrand (Red Hat)
2025-11-13 18:44     ` Christophe Leroy [this message]
2025-11-17 10:16     ` Lorenzo Stoakes
2025-11-14 19:43 ` David Hildenbrand (Red Hat)

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=027b6ac9-836d-4f89-a819-e24d487f9c8e@kernel.org \
    --to=chleroy@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=donettom@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=maddy@linux.ibm.com \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ritesh.list@gmail.com \
    --cc=rppt@kernel.org \
    --cc=sourabhjain@linux.ibm.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /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