| Message ID | cover.1711377230.git.christophe.leroy@csgroup.eu (mailing list archive) |
|---|---|
| Headers | show |
| Series | Reimplement huge pages without hugepd on powerpc 8xx | expand |
On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: > This series reimplements hugepages with hugepd on powerpc 8xx. > > Unlike most architectures, powerpc 8xx HW requires a two-level > pagetable topology for all page sizes. So a leaf PMD-contig approach > is not feasible as such. > > Possible sizes are 4k, 16k, 512k and 8M. > > First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries > must point to a single entry level-2 page table. Until now that was > done using hugepd. This series changes it to use standard page tables > where the entry is replicated 1024 times on each of the two pagetables > refered by the two associated PMD entries for that 8M page. > > At the moment it has to look into each helper to know if the > hugepage ptep is a PTE or a PMD in order to know it is a 8M page or > a lower size. I hope this can me handled by core-mm in the future. > > There are probably several ways to implement stuff, so feedback is > very welcome. I thought it looks pretty good! Thanks, Jason
On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: > On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: > > This series reimplements hugepages with hugepd on powerpc 8xx. > > > > Unlike most architectures, powerpc 8xx HW requires a two-level > > pagetable topology for all page sizes. So a leaf PMD-contig approach > > is not feasible as such. > > > > Possible sizes are 4k, 16k, 512k and 8M. > > > > First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries > > must point to a single entry level-2 page table. Until now that was > > done using hugepd. This series changes it to use standard page tables > > where the entry is replicated 1024 times on each of the two pagetables > > refered by the two associated PMD entries for that 8M page. > > > > At the moment it has to look into each helper to know if the > > hugepage ptep is a PTE or a PMD in order to know it is a 8M page or > > a lower size. I hope this can me handled by core-mm in the future. > > > > There are probably several ways to implement stuff, so feedback is > > very welcome. > > I thought it looks pretty good! I second it. I saw the discussions in patch 1. Christophe, I suppose you're exploring the big hammer over hugepd, and perhaps went already with the 32bit pmd solution for nohash/32bit challenge you mentioned? I'm trying to position my next step; it seems like at least I should not adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD checks, or you're going to have an RFC soon then I can base on top? Thanks,
Le 11/04/2024 à 18:15, Peter Xu a écrit : > On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: >> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: >>> This series reimplements hugepages with hugepd on powerpc 8xx. >>> >>> Unlike most architectures, powerpc 8xx HW requires a two-level >>> pagetable topology for all page sizes. So a leaf PMD-contig approach >>> is not feasible as such. >>> >>> Possible sizes are 4k, 16k, 512k and 8M. >>> >>> First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries >>> must point to a single entry level-2 page table. Until now that was >>> done using hugepd. This series changes it to use standard page tables >>> where the entry is replicated 1024 times on each of the two pagetables >>> refered by the two associated PMD entries for that 8M page. >>> >>> At the moment it has to look into each helper to know if the >>> hugepage ptep is a PTE or a PMD in order to know it is a 8M page or >>> a lower size. I hope this can me handled by core-mm in the future. >>> >>> There are probably several ways to implement stuff, so feedback is >>> very welcome. >> >> I thought it looks pretty good! > > I second it. > > I saw the discussions in patch 1. Christophe, I suppose you're exploring > the big hammer over hugepd, and perhaps went already with the 32bit pmd > solution for nohash/32bit challenge you mentioned? > > I'm trying to position my next step; it seems like at least I should not > adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD checks, > or you're going to have an RFC soon then I can base on top? Depends on what you expect by "soon". I sure won't be able to send any RFC before end of April. Should be possible to have something during May. Christophe
On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: > > > Le 11/04/2024 à 18:15, Peter Xu a écrit : > > On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: > >> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: > >>> This series reimplements hugepages with hugepd on powerpc 8xx. > >>> > >>> Unlike most architectures, powerpc 8xx HW requires a two-level > >>> pagetable topology for all page sizes. So a leaf PMD-contig approach > >>> is not feasible as such. > >>> > >>> Possible sizes are 4k, 16k, 512k and 8M. > >>> > >>> First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries > >>> must point to a single entry level-2 page table. Until now that was > >>> done using hugepd. This series changes it to use standard page tables > >>> where the entry is replicated 1024 times on each of the two pagetables > >>> refered by the two associated PMD entries for that 8M page. > >>> > >>> At the moment it has to look into each helper to know if the > >>> hugepage ptep is a PTE or a PMD in order to know it is a 8M page or > >>> a lower size. I hope this can me handled by core-mm in the future. > >>> > >>> There are probably several ways to implement stuff, so feedback is > >>> very welcome. > >> > >> I thought it looks pretty good! > > > > I second it. > > > > I saw the discussions in patch 1. Christophe, I suppose you're exploring > > the big hammer over hugepd, and perhaps went already with the 32bit pmd > > solution for nohash/32bit challenge you mentioned? > > > > I'm trying to position my next step; it seems like at least I should not > > adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD checks, > > or you're going to have an RFC soon then I can base on top? > > Depends on what you expect by "soon". > > I sure won't be able to send any RFC before end of April. > > Should be possible to have something during May. That's good enough, thanks. I'll see what is the best I can do. Then do you think I can leave p4d/pgd leaves alone? Please check the other email where I'm not sure whether pgd leaves ever existed for any of PowerPC. That's so far what I plan to do, on teaching pgtable walkers recognize pud and lower for all leaves. Then if Power can switch from hugepd to this it should just work. Even if pgd exists (then something I overlooked..), I'm wondering whether we can push that downwards to be either pud/pmd (and looks like we all agree p4d is never used on Power). That may involve some pgtable operations moving from pgd level to lower, e.g. my pure imagination would look like starting with: #define PTE_INDEX_SIZE PTE_SHIFT #define PMD_INDEX_SIZE 0 #define PUD_INDEX_SIZE 0 #define PGD_INDEX_SIZE (32 - PGDIR_SHIFT) To: #define PTE_INDEX_SIZE PTE_SHIFT #define PMD_INDEX_SIZE (32 - PMD_SHIFT) #define PUD_INDEX_SIZE 0 #define PGD_INDEX_SIZE 0 And the rest will need care too. I hope moving downward is easier (e.g. the walker should always exist for lower levels but not always for higher levels), but I actually have little idea on whether there's any other implications, so please bare with me on stupid mistakes. I just hope pgd leaves don't exist already, then I think it'll be simpler. Thanks,
Le 12/04/2024 à 16:30, Peter Xu a écrit : > On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: >> >> >> Le 11/04/2024 à 18:15, Peter Xu a écrit : >>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: >>>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: >>>>> This series reimplements hugepages with hugepd on powerpc 8xx. >>>>> >>>>> Unlike most architectures, powerpc 8xx HW requires a two-level >>>>> pagetable topology for all page sizes. So a leaf PMD-contig approach >>>>> is not feasible as such. >>>>> >>>>> Possible sizes are 4k, 16k, 512k and 8M. >>>>> >>>>> First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries >>>>> must point to a single entry level-2 page table. Until now that was >>>>> done using hugepd. This series changes it to use standard page tables >>>>> where the entry is replicated 1024 times on each of the two pagetables >>>>> refered by the two associated PMD entries for that 8M page. >>>>> >>>>> At the moment it has to look into each helper to know if the >>>>> hugepage ptep is a PTE or a PMD in order to know it is a 8M page or >>>>> a lower size. I hope this can me handled by core-mm in the future. >>>>> >>>>> There are probably several ways to implement stuff, so feedback is >>>>> very welcome. >>>> >>>> I thought it looks pretty good! >>> >>> I second it. >>> >>> I saw the discussions in patch 1. Christophe, I suppose you're exploring >>> the big hammer over hugepd, and perhaps went already with the 32bit pmd >>> solution for nohash/32bit challenge you mentioned? >>> >>> I'm trying to position my next step; it seems like at least I should not >>> adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD checks, >>> or you're going to have an RFC soon then I can base on top? >> >> Depends on what you expect by "soon". >> >> I sure won't be able to send any RFC before end of April. >> >> Should be possible to have something during May. > > That's good enough, thanks. I'll see what is the best I can do. > > Then do you think I can leave p4d/pgd leaves alone? Please check the other > email where I'm not sure whether pgd leaves ever existed for any of > PowerPC. That's so far what I plan to do, on teaching pgtable walkers > recognize pud and lower for all leaves. Then if Power can switch from > hugepd to this it should just work. Well, if I understand correctly, something with no PMD will include <asm-generic/pgtable-nopmd.h> and will therefore only have .... pmd entries (hence no pgd/p4d/pud entries). Looks odd but that's what it is. pgd_populate(), p4d_populate(), pud_populate() are all "do { } while (0)" and only pmd_populate exists. So only pmd_leaf() will exist in that case. And therefore including <asm-generic/pgtable-nop4d.h> means .... you have p4d entries. Doesn't mean you have p4d_leaf() but that needs to be checked. > > Even if pgd exists (then something I overlooked..), I'm wondering whether > we can push that downwards to be either pud/pmd (and looks like we all > agree p4d is never used on Power). That may involve some pgtable > operations moving from pgd level to lower, e.g. my pure imagination would > look like starting with: Yes I think there is no doubt that p4d is never used: arch/powerpc/include/asm/book3s/32/pgtable.h:#include <asm-generic/pgtable-nopmd.h> arch/powerpc/include/asm/book3s/64/pgtable.h:#include <asm-generic/pgtable-nop4d.h> arch/powerpc/include/asm/nohash/32/pgtable.h:#include <asm-generic/pgtable-nopmd.h> arch/powerpc/include/asm/nohash/64/pgtable-4k.h:#include <asm-generic/pgtable-nop4d.h> But that means that PPC32 have pmd entries and PPC64 have p4d entries ... > > #define PTE_INDEX_SIZE PTE_SHIFT > #define PMD_INDEX_SIZE 0 > #define PUD_INDEX_SIZE 0 > #define PGD_INDEX_SIZE (32 - PGDIR_SHIFT) > > To: > > #define PTE_INDEX_SIZE PTE_SHIFT > #define PMD_INDEX_SIZE (32 - PMD_SHIFT) > #define PUD_INDEX_SIZE 0 > #define PGD_INDEX_SIZE 0 But then you can't anymore have #define PTRS_PER_PMD 1 from <asm-generic/pgtable-nop4d.h> > > And the rest will need care too. I hope moving downward is easier > (e.g. the walker should always exist for lower levels but not always for > higher levels), but I actually have little idea on whether there's any > other implications, so please bare with me on stupid mistakes. > > I just hope pgd leaves don't exist already, then I think it'll be simpler. > > Thanks, >
Le 15/04/2024 à 21:12, Christophe Leroy a écrit : > > > Le 12/04/2024 à 16:30, Peter Xu a écrit : >> On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: >>> >>> >>> Le 11/04/2024 à 18:15, Peter Xu a écrit : >>>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: >>>>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: >>>>>> This series reimplements hugepages with hugepd on powerpc 8xx. >>>>>> >>>>>> Unlike most architectures, powerpc 8xx HW requires a two-level >>>>>> pagetable topology for all page sizes. So a leaf PMD-contig approach >>>>>> is not feasible as such. >>>>>> >>>>>> Possible sizes are 4k, 16k, 512k and 8M. >>>>>> >>>>>> First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD >>>>>> entries >>>>>> must point to a single entry level-2 page table. Until now that was >>>>>> done using hugepd. This series changes it to use standard page tables >>>>>> where the entry is replicated 1024 times on each of the two >>>>>> pagetables >>>>>> refered by the two associated PMD entries for that 8M page. >>>>>> >>>>>> At the moment it has to look into each helper to know if the >>>>>> hugepage ptep is a PTE or a PMD in order to know it is a 8M page or >>>>>> a lower size. I hope this can me handled by core-mm in the future. >>>>>> >>>>>> There are probably several ways to implement stuff, so feedback is >>>>>> very welcome. >>>>> >>>>> I thought it looks pretty good! >>>> >>>> I second it. >>>> >>>> I saw the discussions in patch 1. Christophe, I suppose you're >>>> exploring >>>> the big hammer over hugepd, and perhaps went already with the 32bit pmd >>>> solution for nohash/32bit challenge you mentioned? >>>> >>>> I'm trying to position my next step; it seems like at least I should >>>> not >>>> adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD >>>> checks, >>>> or you're going to have an RFC soon then I can base on top? >>> >>> Depends on what you expect by "soon". >>> >>> I sure won't be able to send any RFC before end of April. >>> >>> Should be possible to have something during May. >> >> That's good enough, thanks. I'll see what is the best I can do. >> >> Then do you think I can leave p4d/pgd leaves alone? Please check the >> other >> email where I'm not sure whether pgd leaves ever existed for any of >> PowerPC. That's so far what I plan to do, on teaching pgtable walkers >> recognize pud and lower for all leaves. Then if Power can switch from >> hugepd to this it should just work. > > Well, if I understand correctly, something with no PMD will include > <asm-generic/pgtable-nopmd.h> and will therefore only have .... pmd > entries (hence no pgd/p4d/pud entries). Looks odd but that's what it is. > pgd_populate(), p4d_populate(), pud_populate() are all "do { } while > (0)" and only pmd_populate exists. So only pmd_leaf() will exist in that > case. > > And therefore including <asm-generic/pgtable-nop4d.h> means .... you > have p4d entries. Doesn't mean you have p4d_leaf() but that needs to be > checked. > > >> >> Even if pgd exists (then something I overlooked..), I'm wondering whether >> we can push that downwards to be either pud/pmd (and looks like we all >> agree p4d is never used on Power). That may involve some pgtable >> operations moving from pgd level to lower, e.g. my pure imagination would >> look like starting with: > > Yes I think there is no doubt that p4d is never used: > > arch/powerpc/include/asm/book3s/32/pgtable.h:#include > <asm-generic/pgtable-nopmd.h> > arch/powerpc/include/asm/book3s/64/pgtable.h:#include > <asm-generic/pgtable-nop4d.h> > arch/powerpc/include/asm/nohash/32/pgtable.h:#include > <asm-generic/pgtable-nopmd.h> > arch/powerpc/include/asm/nohash/64/pgtable-4k.h:#include > <asm-generic/pgtable-nop4d.h> > > But that means that PPC32 have pmd entries and PPC64 have p4d entries ... > >> >> #define PTE_INDEX_SIZE PTE_SHIFT >> #define PMD_INDEX_SIZE 0 >> #define PUD_INDEX_SIZE 0 >> #define PGD_INDEX_SIZE (32 - PGDIR_SHIFT) >> >> To: >> >> #define PTE_INDEX_SIZE PTE_SHIFT >> #define PMD_INDEX_SIZE (32 - PMD_SHIFT) >> #define PUD_INDEX_SIZE 0 >> #define PGD_INDEX_SIZE 0 > > But then you can't anymore have #define PTRS_PER_PMD 1 from > <asm-generic/pgtable-nop4d.h> > >> >> And the rest will need care too. I hope moving downward is easier >> (e.g. the walker should always exist for lower levels but not always for >> higher levels), but I actually have little idea on whether there's any >> other implications, so please bare with me on stupid mistakes. >> >> I just hope pgd leaves don't exist already, then I think it'll be >> simpler. >> >> Thanks, >> Digging into asm-generic/pgtable-nopmd.h, I see a definition of pud_leaf() always returning 0, introduced by commit 2c8a81dc0cc5 ("riscv/mm: fix two page table check related issues") So should asm-generic/pgtable-nopud.h contain the same for p4d_leaf() and asm-generic/pgtable-nop4d.h contain the same for pgd_leaf() ? Christophe
On Tue, Apr 16, 2024 at 10:58:33AM +0000, Christophe Leroy wrote: > > > Le 15/04/2024 à 21:12, Christophe Leroy a écrit : > > > > > > Le 12/04/2024 à 16:30, Peter Xu a écrit : > >> On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote: > >>> > >>> > >>> Le 11/04/2024 à 18:15, Peter Xu a écrit : > >>>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote: > >>>>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote: > >>>>>> This series reimplements hugepages with hugepd on powerpc 8xx. > >>>>>> > >>>>>> Unlike most architectures, powerpc 8xx HW requires a two-level > >>>>>> pagetable topology for all page sizes. So a leaf PMD-contig approach > >>>>>> is not feasible as such. > >>>>>> > >>>>>> Possible sizes are 4k, 16k, 512k and 8M. > >>>>>> > >>>>>> First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD > >>>>>> entries > >>>>>> must point to a single entry level-2 page table. Until now that was > >>>>>> done using hugepd. This series changes it to use standard page tables > >>>>>> where the entry is replicated 1024 times on each of the two > >>>>>> pagetables > >>>>>> refered by the two associated PMD entries for that 8M page. > >>>>>> > >>>>>> At the moment it has to look into each helper to know if the > >>>>>> hugepage ptep is a PTE or a PMD in order to know it is a 8M page or > >>>>>> a lower size. I hope this can me handled by core-mm in the future. > >>>>>> > >>>>>> There are probably several ways to implement stuff, so feedback is > >>>>>> very welcome. > >>>>> > >>>>> I thought it looks pretty good! > >>>> > >>>> I second it. > >>>> > >>>> I saw the discussions in patch 1. Christophe, I suppose you're > >>>> exploring > >>>> the big hammer over hugepd, and perhaps went already with the 32bit pmd > >>>> solution for nohash/32bit challenge you mentioned? > >>>> > >>>> I'm trying to position my next step; it seems like at least I should > >>>> not > >>>> adding any more hugepd code, then should I go with ARCH_HAS_HUGEPD > >>>> checks, > >>>> or you're going to have an RFC soon then I can base on top? > >>> > >>> Depends on what you expect by "soon". > >>> > >>> I sure won't be able to send any RFC before end of April. > >>> > >>> Should be possible to have something during May. > >> > >> That's good enough, thanks. I'll see what is the best I can do. > >> > >> Then do you think I can leave p4d/pgd leaves alone? Please check the > >> other > >> email where I'm not sure whether pgd leaves ever existed for any of > >> PowerPC. That's so far what I plan to do, on teaching pgtable walkers > >> recognize pud and lower for all leaves. Then if Power can switch from > >> hugepd to this it should just work. > > > > Well, if I understand correctly, something with no PMD will include > > <asm-generic/pgtable-nopmd.h> and will therefore only have .... pmd > > entries (hence no pgd/p4d/pud entries). Looks odd but that's what it is. > > pgd_populate(), p4d_populate(), pud_populate() are all "do { } while > > (0)" and only pmd_populate exists. So only pmd_leaf() will exist in that > > case. > > > > And therefore including <asm-generic/pgtable-nop4d.h> means .... you > > have p4d entries. Doesn't mean you have p4d_leaf() but that needs to be > > checked. > > > > > >> > >> Even if pgd exists (then something I overlooked..), I'm wondering whether > >> we can push that downwards to be either pud/pmd (and looks like we all > >> agree p4d is never used on Power). That may involve some pgtable > >> operations moving from pgd level to lower, e.g. my pure imagination would > >> look like starting with: > > > > Yes I think there is no doubt that p4d is never used: > > > > arch/powerpc/include/asm/book3s/32/pgtable.h:#include > > <asm-generic/pgtable-nopmd.h> > > arch/powerpc/include/asm/book3s/64/pgtable.h:#include > > <asm-generic/pgtable-nop4d.h> > > arch/powerpc/include/asm/nohash/32/pgtable.h:#include > > <asm-generic/pgtable-nopmd.h> > > arch/powerpc/include/asm/nohash/64/pgtable-4k.h:#include > > <asm-generic/pgtable-nop4d.h> > > > > But that means that PPC32 have pmd entries and PPC64 have p4d entries ... > > > >> > >> #define PTE_INDEX_SIZE PTE_SHIFT > >> #define PMD_INDEX_SIZE 0 > >> #define PUD_INDEX_SIZE 0 > >> #define PGD_INDEX_SIZE (32 - PGDIR_SHIFT) > >> > >> To: > >> > >> #define PTE_INDEX_SIZE PTE_SHIFT > >> #define PMD_INDEX_SIZE (32 - PMD_SHIFT) > >> #define PUD_INDEX_SIZE 0 > >> #define PGD_INDEX_SIZE 0 > > > > But then you can't anymore have #define PTRS_PER_PMD 1 from > > <asm-generic/pgtable-nop4d.h> > > > >> > >> And the rest will need care too. I hope moving downward is easier > >> (e.g. the walker should always exist for lower levels but not always for > >> higher levels), but I actually have little idea on whether there's any > >> other implications, so please bare with me on stupid mistakes. > >> > >> I just hope pgd leaves don't exist already, then I think it'll be > >> simpler. > >> > >> Thanks, > >> > > Digging into asm-generic/pgtable-nopmd.h, I see a definition of > pud_leaf() always returning 0, introduced by commit 2c8a81dc0cc5 > ("riscv/mm: fix two page table check related issues") > > So should asm-generic/pgtable-nopud.h contain the same for p4d_leaf() I think should be yes for this, and.. > and asm-generic/pgtable-nop4d.h contain the same for pgd_leaf() ? .. probably no for this? It seems pgd is just slightly special. Firstly, I notice that the -nopmd.h actually includes -nopud.h already, and further that includes -nop4d.h. It means we can only have below options: a) nopmd + nopud + nop4d b) nopud + nop4d c) nop4d It should also mean we can't randomly choose which layer to skip with the current header arrangements.. at the meantime, all 32bit PowerPC should perhaps fall into a), while 64 bits fall into c). That looks all fine for now. Above p4d_leaf()==false [1] should be fine when -nopud.h included, because that already included nop4d.h, it means "p4d level is skipped" in the pgtable. Then it doesn't make sense if p4d_leaf() can ever return true. That's the same when pud_leaf()==false looks sane when an arch included -nopmd.h as that in turn implies -nopud too. pgd seems different, because -nop4d.h didn't include anything else like "-nopgd.h".. so I don't see further implication on pgd sololy from the headers. I guess that's also why 32bit Power uses pgd+pte for the two levels; it looks like pgd is special among the others. However I think it still didn't mean that we can't push pgd to pmd, making pgd+pte into pmd+pte. Though here we may want to move from: #include <asm-generic/pgtable-nopmd.h> (pmd/pud/p4d not used) Into: #include <asm-generic/pgtable-nopud.h> (pud/p4d not used) Then we may need to provide something similar to what's in -nopXd.h for pgds. But let's loop back to the very beginning: I don't think we have either pgd leaves or p4d leaves for PowerPC. Note that hugepd looks possible to exist in pgd entries (per wiki page [1]), however I don't even think it's true in reality, as I mentioned elsewhere on reading __find_linux_pte() and it always go directly into p4d. I highly doubt in reality the "pgd hugepd entries" are actually processed by the p4d layer here: if (is_hugepd(__hugepd(p4d_val(p4d)))) { hpdp = (hugepd_t *)&p4d; goto out_huge; } Because when with "nop4d" it doesn't mean "there is no p4d" but what it really meant is "we have only one p4d entry (which is actually exactly the pgd entry..)". After all, is_hugepd() works for all levels. Taking E500 nohash 32 as example, it has these: "pgd entry covering 2M" -> "hugepd with one hugepte covering one 4M hugepage" ^ "pgd entry covering 2M" ---------+ I suspect this "pgd covering 2M" is processed by the p4d code above, rather than pgd level. Then in the future world where there's no hugepd, it'll naturally become a pgtable page at pte level. Thanks, [1] https://github.com/linuxppc/wiki/wiki/Huge-pages
This series reimplements hugepages with hugepd on powerpc 8xx. Unlike most architectures, powerpc 8xx HW requires a two-level pagetable topology for all page sizes. So a leaf PMD-contig approach is not feasible as such. Possible sizes are 4k, 16k, 512k and 8M. First level (PGD/PMD) covers 4M per entry. For 8M pages, two PMD entries must point to a single entry level-2 page table. Until now that was done using hugepd. This series changes it to use standard page tables where the entry is replicated 1024 times on each of the two pagetables refered by the two associated PMD entries for that 8M page. At the moment it has to look into each helper to know if the hugepage ptep is a PTE or a PMD in order to know it is a 8M page or a lower size. I hope this can me handled by core-mm in the future. There are probably several ways to implement stuff, so feedback is very welcome. Christophe Leroy (8): mm: Provide pagesize to pmd_populate() mm: Provide page size to pte_alloc_huge() mm: Provide pmd to pte_leaf_size() mm: Provide mm_struct and address to huge_ptep_get() powerpc/mm: Allow hugepages without hugepd powerpc/8xx: Fix size given to set_huge_pte_at() powerpc/8xx: Remove support for 8M pages powerpc/8xx: Add back support for 8M pages using contiguous PTE entries arch/arm64/include/asm/hugetlb.h | 2 +- arch/arm64/include/asm/pgtable.h | 2 +- arch/arm64/mm/hugetlbpage.c | 2 +- arch/parisc/mm/hugetlbpage.c | 2 +- arch/powerpc/Kconfig | 1 - arch/powerpc/include/asm/hugetlb.h | 13 +++- .../include/asm/nohash/32/hugetlb-8xx.h | 54 ++++++++--------- arch/powerpc/include/asm/nohash/32/pgalloc.h | 2 + arch/powerpc/include/asm/nohash/32/pte-8xx.h | 59 +++++++++++++------ arch/powerpc/include/asm/nohash/pgtable.h | 12 ++-- arch/powerpc/include/asm/page.h | 5 -- arch/powerpc/include/asm/pgtable.h | 1 + arch/powerpc/kernel/head_8xx.S | 10 +--- arch/powerpc/mm/hugetlbpage.c | 23 +++++++- arch/powerpc/mm/nohash/8xx.c | 46 +++++++-------- arch/powerpc/mm/pgtable.c | 26 +++++--- arch/powerpc/mm/pgtable_32.c | 2 +- arch/powerpc/platforms/Kconfig.cputype | 2 + arch/riscv/include/asm/pgtable.h | 2 +- arch/riscv/mm/hugetlbpage.c | 2 +- arch/sh/mm/hugetlbpage.c | 2 +- arch/sparc/include/asm/pgtable_64.h | 2 +- arch/sparc/mm/hugetlbpage.c | 4 +- fs/hugetlbfs/inode.c | 2 +- fs/proc/task_mmu.c | 8 +-- fs/userfaultfd.c | 2 +- include/asm-generic/hugetlb.h | 2 +- include/linux/hugetlb.h | 4 +- include/linux/mm.h | 12 ++-- include/linux/pgtable.h | 2 +- include/linux/swapops.h | 2 +- kernel/events/core.c | 2 +- mm/damon/vaddr.c | 6 +- mm/filemap.c | 2 +- mm/gup.c | 2 +- mm/hmm.c | 2 +- mm/hugetlb.c | 46 +++++++-------- mm/internal.h | 2 +- mm/memory-failure.c | 2 +- mm/memory.c | 19 +++--- mm/mempolicy.c | 2 +- mm/migrate.c | 4 +- mm/mincore.c | 2 +- mm/pgalloc-track.h | 2 +- mm/userfaultfd.c | 6 +- 45 files changed, 229 insertions(+), 180 deletions(-)