[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87plrwj56s.fsf@mail.lhotse>
Date: Tue, 02 Jul 2024 23:26:19 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Christophe Leroy <christophe.leroy@...roup.eu>, Andrew Morton
<akpm@...ux-foundation.org>, Jason Gunthorpe <jgg@...dia.com>, Peter Xu
<peterx@...hat.com>, Oscar Salvador <osalvador@...e.de>, Nicholas Piggin
<npiggin@...il.com>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v6 21/23] powerpc/64s: Use contiguous PMD/PUD instead of
HUGEPD
Christophe Leroy <christophe.leroy@...roup.eu> writes:
> On book3s/64, the only user of hugepd is hash in 4k mode.
>
> All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD.
>
> Rework hash-4k to use contiguous PMD and PUD instead.
>
> In that setup there are only two huge page sizes: 16M and 16G.
>
> 16M sits at PMD level and 16G at PUD level.
>
> pte_update doesn't know page size, lets use the same trick as
> hpte_need_flush() to get page size from segment properties. That's
> not the most efficient way but let's do that until callers of
> pte_update() provide page size instead of just a huge flag.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@...roup.eu>
> ---
> v3:
> - Add missing pmd_leaf_size() and pud_leaf_size()
> - More cleanup in hugetlbpage_init()
> - Take a page fault when DIRTY or ACCESSED is missing on hash-4 hugepage
>
> v4: Rebased on v6.10-rc1
>
> v6: Added a WARN_ON_ONCE() in hash__pte_update() in case the pagesize is unexpected.
> ---
> arch/powerpc/include/asm/book3s/64/hash-4k.h | 15 ------
> arch/powerpc/include/asm/book3s/64/hash.h | 40 +++++++++++++---
> arch/powerpc/include/asm/book3s/64/hugetlb.h | 38 ---------------
> .../include/asm/book3s/64/pgtable-4k.h | 47 -------------------
> .../include/asm/book3s/64/pgtable-64k.h | 20 --------
> arch/powerpc/include/asm/book3s/64/pgtable.h | 22 +++++++--
> arch/powerpc/include/asm/hugetlb.h | 4 ++
> .../powerpc/include/asm/nohash/hugetlb-e500.h | 4 --
> arch/powerpc/include/asm/page.h | 8 ----
> arch/powerpc/mm/book3s64/hash_utils.c | 11 +++--
> arch/powerpc/mm/book3s64/hugetlbpage.c | 10 ++++
> arch/powerpc/mm/book3s64/pgtable.c | 12 -----
> arch/powerpc/mm/hugetlbpage.c | 26 ----------
> arch/powerpc/mm/pgtable.c | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 1 -
> 15 files changed, 74 insertions(+), 186 deletions(-)
> delete mode 100644 arch/powerpc/include/asm/book3s/64/pgtable-4k.h
This looks good to me. I've run a few tests on it and haven't seen any
issues.
I also dumped the page tables of a test program and checked they looked
sensible. And I checked that the hash insert path is actually inserting
a huge page entry (of course it is, but just to be sure).
On mainline using a hugepd page hits the first warning in
try_grab_folio() (via gup_hugepd()) and hangs the process. I haven't
seen that reported (it goes back to v6.5), so my impression is hugepd on
hash-4k is essentially unused these days.
This series is an improvement on that, so let's get it into mm-unstable
for some wider testing.
Acked-by: Michael Ellerman <mpe@...erman.id.au> (powerpc)
cheers
Powered by blists - more mailing lists