From: Michael Ellerman <mpe@ellerman.id.au>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Cc: "mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"aneesh.kumar@linux.ibm.com" <aneesh.kumar@linux.ibm.com>
Subject: Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf()
Date: Sun, 04 Sep 2022 21:32:39 +1000 [thread overview]
Message-ID: <87leqztlwo.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <4c607d70-6b1e-46d1-72f2-8bbf0fc40949@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 03/09/2022 à 14:36, Michael Ellerman a écrit :
>> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the
>> PGD. So P4D entries are actually PGD entries, or vice versa.
>>
>> The other way to think of it is that the P4D is a single entry page
>> table below the PGD. Zero bits of the address are needed to index into
>> the P4D, therefore a P4D entry maps the same size address space as a PGD
>> entry.
>>
>> As explained in the previous commit, there are no huge page sizes
>> supported directly at the PGD level on 64-bit Book3S, so there are also
>> no huge page sizes supported at the P4D level.
>>
>> Therefore p4d_is_leaf() can never be true, so drop the definition and
>> fallback to the default implementation that always returns false.
>
> Then here as well, you are removing the only architecture which
> implements a non 'always false' version of p4d_leaf().
>
> x86 has on that is always false:
>
> #define p4d_leaf p4d_large
> static inline int p4d_large(p4d_t p4d)
> {
> /* No 512 GiB pages yet */
> return 0;
> }
>
> So, should it be dropped as well and all uses removed from core mm ?
Probably?
I see very few uses of p4d_leaf(), so I suspect it's not actually being
called in all the places it should be if it ever returned true. See eg.
follow_p4d_mask() which doesn't call it.
I think it would be best to remove it and if anyone ever implements huge
pages at that level (unlikely?) they will need to go back and add
support in the right places.
But ultimately it's up to the mm folks to decide IMHO.
cheers
next prev parent reply other threads:[~2022-09-04 11:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-03 12:36 [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge() Michael Ellerman
2022-09-03 12:36 ` [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf() Michael Ellerman
2022-09-03 15:11 ` Christophe Leroy
2022-09-04 11:32 ` Michael Ellerman [this message]
2022-09-04 16:57 ` Aneesh Kumar K.V
2022-09-03 15:06 ` [PATCH 1/2] powerpc/mm/64s: Drop pgd_huge() Christophe Leroy
2022-09-04 11:24 ` Michael Ellerman
2022-09-04 16:57 ` Aneesh Kumar K.V
2022-10-04 13:24 ` Michael Ellerman
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=87leqztlwo.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=aneesh.kumar@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mike.kravetz@oracle.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