linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Xu <peterx@redhat.com>, Oscar Salvador <osalvador@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC PATCH v2 18/20] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD
Date: Wed, 22 May 2024 09:23:55 -0300	[thread overview]
Message-ID: <20240522122355.GR20229@nvidia.com> (raw)
In-Reply-To: <D1FRWM5DHHOT.3EAJGCLO0YTND@gmail.com>

On Wed, May 22, 2024 at 11:13:53AM +1000, Nicholas Piggin wrote:

> From the mm/ side of things, hugetlb page tables are always walked via
> the huge vma which knows the page size and could align address... I
> guess except for fast gup? Which should be read-only. So okay you do
> need to replicate huge ptes for fast gup at least. Any others?

We are trying to get away from this. We want all content in the page
table to be walkable via the normal pud/pmd/pte/etc functions and the
special huge VMA limited to only weird hugetlbfs internals. It should
not leak into the arch.

> There's going to need to be a little more to it. __hash_page_huge sets
> PTE accessed and dirty for example, so if we allow any PTE readers to
> check the non-0th pte we would have to do something about that.

Ryan added a special function to get the access and dirty flags from a
CONTIG PTE, the arch can do the right thing here. The case where there
was a CONTIG PTE that spanned two PMD entries might be some trouble
though.

> How do you deal with dirty/accessed bits for other subarchs?

ARM and RISCV verions will combine the access flags from every sub
pte. Their HW is allowed to set dirty/access bits on any PTE in a
contiguos set.

Jason


  parent reply	other threads:[~2024-05-22 12:24 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 18:59 [RFC PATCH v2 00/20] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 01/20] mm: Provide pagesize to pmd_populate() Christophe Leroy
2024-05-20  9:01   ` Oscar Salvador
2024-05-20 16:24     ` Christophe Leroy
2024-05-21 11:57       ` Oscar Salvador
2024-05-22  8:37         ` Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 02/20] mm: Provide page size to pte_alloc_huge() Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 03/20] mm: Provide pmd to pte_leaf_size() Christophe Leroy
2024-05-21  9:39   ` Oscar Salvador
2024-05-22 10:22     ` Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 04/20] mm: Provide mm_struct and address to huge_ptep_get() Christophe Leroy
2024-05-17 18:59 ` [RFC PATCH v2 05/20] powerpc/mm: Allow hugepages without hugepd Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 06/20] powerpc/8xx: Fix size given to set_huge_pte_at() Christophe Leroy
2024-05-20  9:14   ` Oscar Salvador
2024-05-20 16:31     ` Christophe Leroy
2024-05-20 17:42       ` Oscar Salvador
2024-05-22  8:45         ` Christophe Leroy
2024-05-21  0:48       ` Michael Ellerman
2024-05-21  9:26         ` Oscar Salvador
2024-05-22  8:32           ` Christophe Leroy
2024-05-22 12:18             ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 07/20] powerpc/8xx: Rework support for 8M pages using contiguous PTE entries Christophe Leroy
2024-05-24 10:02   ` Oscar Salvador
2024-05-24 11:47     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 08/20] powerpc/8xx: Simplify struct mmu_psize_def Christophe Leroy
2024-05-25  3:36   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 09/20] powerpc/mm: Remove _PAGE_PSIZE Christophe Leroy
2024-05-25  3:40   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 10/20] powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries Christophe Leroy
2024-05-25  4:12   ` Oscar Salvador
2024-05-25  6:41     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 11/20] powerpc/mm: Complement huge_pte_alloc() for all non HUGEPD setups Christophe Leroy
2024-05-25  4:29   ` Oscar Salvador
2024-05-25  6:44     ` Christophe Leroy
2024-05-25 10:33       ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 12/20] powerpc/64e: Remove unneeded #ifdef CONFIG_PPC_E500 Christophe Leroy
2024-05-24  7:31   ` Michael Ellerman
2024-05-24  8:45     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 13/20] powerpc/64e: Clean up impossible setups Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 14/20] powerpc/e500: Remove enc field from struct mmu_psize_def Christophe Leroy
2024-05-25  4:35   ` Oscar Salvador
2024-05-17 19:00 ` [RFC PATCH v2 15/20] powerpc/85xx: Switch to 64 bits PGD Christophe Leroy
2024-05-25  4:54   ` Oscar Salvador
2024-05-25  9:02     ` Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 16/20] powerpc/e500: Encode hugepage size in PTE bits Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 17/20] powerpc/e500: Use contiguous PMD instead of hugepd Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 18/20] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD Christophe Leroy
2024-05-20 12:54   ` Nicholas Piggin
2024-05-20 16:43     ` Christophe Leroy
2024-05-22  1:13       ` Nicholas Piggin
2024-05-22  9:32         ` Christophe Leroy
2024-05-22 12:23         ` Jason Gunthorpe [this message]
2024-05-17 19:00 ` [RFC PATCH v2 19/20] powerpc/mm: Remove hugepd leftovers Christophe Leroy
2024-05-17 19:00 ` [RFC PATCH v2 20/20] mm: Remove CONFIG_ARCH_HAS_HUGEPD Christophe Leroy
2024-05-17 19:06 ` [RFC PATCH v2 00/20] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Jason Gunthorpe
2024-05-18  6:28   ` Christophe Leroy
2024-05-23 19:40 ` Peter Xu
2024-05-24  4:46   ` Michael Ellerman
2024-05-27 14:14     ` Peter Xu
2024-05-24  6:31   ` Oscar Salvador

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=20240522122355.GR20229@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.leroy@csgroup.eu \
    --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=osalvador@suse.de \
    --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;
as well as URLs for NNTP newsgroup(s).