From: Oscar Salvador <osalvador@suse.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jason Gunthorpe <jgg@nvidia.com>, Peter Xu <peterx@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH v3 00/16] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64)
Date: Sun, 26 May 2024 13:04:51 +0200 [thread overview]
Message-ID: <ZlMXU_4sbm02jEwe@localhost.localdomain> (raw)
In-Reply-To: <cover.1716714720.git.christophe.leroy@csgroup.eu>
On Sun, May 26, 2024 at 11:22:20AM +0200, Christophe Leroy wrote:
> This is the continuation of the RFC v1 series "Reimplement huge pages
> without hugepd on powerpc 8xx". It now get rid of hugepd completely
> after handling also e500 and book3s/64
>
> Also see https://github.com/linuxppc/issues/issues/483
>
> 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 on 8xx 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.
>
> For e500 and book3s/64 there are less constraints because it is not
> tied to the HW assisted tablewalk like on 8xx, so it is easier to use
> leaf PMDs (and PUDs).
>
> On e500 the supported page sizes are 4M, 16M, 64M, 256M and 1G. All at
> PMD level on e500/32 (mpc85xx) and mix of PMD and PUD for e500/64. We
> encode page size with 4 available bits in PTE entries. On e300/32 PGD
> entries size is increases to 64 bits in order to allow leaf-PMD entries
> because PTE are 64 bits on e500.
>
> On book3s/64 only the hash-4k mode is concerned. It supports 16M pages
> as cont-PMD and 16G pages as cont-PUD. In other modes (radix-4k, radix-6k
> and hash-64k) the sizes match with PMD and PUD sizes so that's just leaf
> entries. The hash processing make things a bit more complex. To ease
> things, __hash_page_huge() is modified to bail out when DIRTY or ACCESSED
> bits are missing, leaving it to mm core to fix it.
>
> Global changes in v3:
> - Removed patches 1 and 2
> - Squashed patch 11 into patch 5
> - Replaced patches 12 and 13 with a series from Michael
> - Reordered patches a bit to have more general patches up front
>
> For more details on changes, see in each patch.
>
> Christophe Leroy (15):
> mm: Define __pte_leaf_size() to also take a PMD entry
> mm: Provide mm_struct and address to huge_ptep_get()
> powerpc/mm: Remove _PAGE_PSIZE
> powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries
> powerpc/mm: Allow hugepages without hugepd
> powerpc/8xx: Fix size given to set_huge_pte_at()
> powerpc/8xx: Rework support for 8M pages using contiguous PTE entries
> powerpc/8xx: Simplify struct mmu_psize_def
> powerpc/e500: Remove enc and ind fields from struct mmu_psize_def
> powerpc/e500: Switch to 64 bits PGD on 85xx (32 bits)
> powerpc/e500: Encode hugepage size in PTE bits
> powerpc/e500: Use contiguous PMD instead of hugepd
> powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD
> powerpc/mm: Remove hugepd leftovers
> mm: Remove CONFIG_ARCH_HAS_HUGEPD
I glanced over it and it looks much better, not having to fiddle with other arch
code and generic declarations is a big plus.
I plan to do a proper review tomorrow.
Thanks for working on this Christophe!
--
Oscar Salvador
SUSE Labs
prev parent reply other threads:[~2024-05-26 11:05 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-26 9:22 Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 01/16] powerpc/64e: Remove unused IBM HTW code [SQUASHED] Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 02/16] mm: Define __pte_leaf_size() to also take a PMD entry Christophe Leroy
2024-05-27 4:52 ` Oscar Salvador
2024-05-26 9:22 ` [RFC PATCH v3 03/16] mm: Provide mm_struct and address to huge_ptep_get() Christophe Leroy
2024-05-27 11:19 ` Oscar Salvador
2024-05-27 15:51 ` Christophe Leroy
2024-05-27 17:38 ` Oscar Salvador
2024-05-26 9:22 ` [RFC PATCH v3 04/16] powerpc/mm: Remove _PAGE_PSIZE Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 05/16] powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries Christophe Leroy
2024-05-27 4:55 ` Oscar Salvador
2024-05-27 5:16 ` Christophe Leroy
2024-05-27 11:25 ` Oscar Salvador
2024-05-26 9:22 ` [RFC PATCH v3 06/16] powerpc/mm: Allow hugepages without hugepd Christophe Leroy
2024-05-27 11:49 ` Oscar Salvador
2024-05-26 9:22 ` [RFC PATCH v3 07/16] powerpc/8xx: Fix size given to set_huge_pte_at() Christophe Leroy
2024-05-27 4:56 ` Oscar Salvador
2024-05-26 9:22 ` [RFC PATCH v3 08/16] powerpc/8xx: Rework support for 8M pages using contiguous PTE entries Christophe Leroy
2024-05-27 12:10 ` Oscar Salvador
2024-05-28 10:53 ` Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 09/16] powerpc/8xx: Simplify struct mmu_psize_def Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 10/16] powerpc/e500: Remove enc and ind fields from " Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 11/16] powerpc/e500: Switch to 64 bits PGD on 85xx (32 bits) Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 12/16] powerpc/e500: Encode hugepage size in PTE bits Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 13/16] powerpc/e500: Use contiguous PMD instead of hugepd Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 14/16] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 15/16] powerpc/mm: Remove hugepd leftovers Christophe Leroy
2024-05-26 9:22 ` [RFC PATCH v3 16/16] mm: Remove CONFIG_ARCH_HAS_HUGEPD Christophe Leroy
2024-05-26 11:04 ` Oscar Salvador [this message]
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=ZlMXU_4sbm02jEwe@localhost.localdomain \
--to=osalvador@suse.de \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jgg@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=peterx@redhat.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