linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.com>
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 v4 14/16] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD
Date: Wed, 29 May 2024 11:23:18 +0200	[thread overview]
Message-ID: <Zlb0BugOwko4PrLm@localhost.localdomain> (raw)
In-Reply-To: <610be6003a6d215e9e9ca87d7f5402042da1e355.1716815901.git.christophe.leroy@csgroup.eu>

On Mon, May 27, 2024 at 03:30:12PM +0200, Christophe Leroy wrote:
> 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.


On 4k mode, PMD_SIZE is 2MB and PUD_SIZE is 256MB, right?

> +static inline unsigned long hash__pte_update(struct mm_struct *mm,
> +					 unsigned long addr,
> +					 pte_t *ptep, unsigned long clr,
> +					 unsigned long set,
> +					 int huge)
> +{
> +	unsigned long old;
> +
> +	old = hash__pte_update_one(ptep, clr, set);
> +
> +	if (IS_ENABLED(CONFIG_PPC_4K_PAGES) && huge) {
> +		unsigned int psize = get_slice_psize(mm, addr);
> +		int nb, i;
> +
> +		if (psize == MMU_PAGE_16M)
> +			nb = SZ_16M / PMD_SIZE;
> +		else if (psize == MMU_PAGE_16G)
> +			nb = SZ_16G / PUD_SIZE;
> +		else
> +			nb = 1;

On 4K, hugepages are either 16M or 16G. How can we end up in a situation
whwere the is pte is huge, but is is neither MMU_PAGE_16G nor MMU_PAGE_16M?

> diff --git a/arch/powerpc/mm/book3s64/hugetlbpage.c b/arch/powerpc/mm/book3s64/hugetlbpage.c
> index 5a2e512e96db..83c3361b358b 100644
> --- a/arch/powerpc/mm/book3s64/hugetlbpage.c
> +++ b/arch/powerpc/mm/book3s64/hugetlbpage.c
> @@ -53,6 +53,16 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
>  		/* If PTE permissions don't match, take page fault */
>  		if (unlikely(!check_pte_access(access, old_pte)))
>  			return 1;
> +		/*
> +		 * If hash-4k, hugepages use seeral contiguous PxD entries
'several'
> +		 * so bail out and let mm make the page young or dirty
> +		 */
> +		if (IS_ENABLED(CONFIG_PPC_4K_PAGES)) {
> +			if (!(old_pte & _PAGE_ACCESSED))
> +				return 1;
> +			if ((access & _PAGE_WRITE) && !(old_pte & _PAGE_DIRTY))
> +				return 1;

I have 0 clue about this code. What would happen if we do not bail out?


-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2024-05-29  9:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-27 13:29 [RFC PATCH v4 00/16] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) Christophe Leroy
2024-05-27 13:29 ` [RFC PATCH v4 01/16] powerpc/64e: Remove unused IBM HTW code [SQUASHED] Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 02/16] mm: Define __pte_leaf_size() to also take a PMD entry Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 03/16] mm: Provide mm_struct and address to huge_ptep_get() Christophe Leroy
2024-05-28  4:12   ` Oscar Salvador
2024-05-28  5:41   ` Oscar Salvador
2024-05-28 11:02     ` Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 04/16] powerpc/mm: Remove _PAGE_PSIZE Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 05/16] powerpc/mm: Fix __find_linux_pte() on 32 bits with PMD leaf entries Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 06/16] powerpc/mm: Allow hugepages without hugepd Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 07/16] powerpc/8xx: Fix size given to set_huge_pte_at() Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 08/16] powerpc/8xx: Rework support for 8M pages using contiguous PTE entries Christophe Leroy
2024-05-29  8:02   ` Oscar Salvador
2024-05-29  9:39     ` Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 09/16] powerpc/8xx: Simplify struct mmu_psize_def Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 10/16] powerpc/e500: Remove enc and ind fields from " Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 11/16] powerpc/e500: Switch to 64 bits PGD on 85xx (32 bits) Christophe Leroy
2024-05-27 13:30 ` [RFC PATCH v4 12/16] powerpc/e500: Encode hugepage size in PTE bits Christophe Leroy
2024-05-29  8:05   ` Oscar Salvador
2024-05-29  9:49     ` Christophe Leroy
2024-05-29 10:09       ` Oscar Salvador
2024-05-29 10:14         ` Christophe Leroy
2024-05-29 10:15           ` Oscar Salvador
2024-05-27 13:30 ` [RFC PATCH v4 13/16] powerpc/e500: Use contiguous PMD instead of hugepd Christophe Leroy
2024-05-29  8:49   ` Oscar Salvador
2024-05-29  9:58     ` Christophe Leroy
2024-05-29 10:05       ` Oscar Salvador
2024-05-27 13:30 ` [RFC PATCH v4 14/16] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD Christophe Leroy
2024-05-29  9:23   ` Oscar Salvador [this message]
2024-05-29 10:07     ` Christophe Leroy
2024-05-29 10:11       ` Oscar Salvador
2024-05-27 13:30 ` [RFC PATCH v4 15/16] powerpc/mm: Remove hugepd leftovers Christophe Leroy
2024-05-29 10:12   ` Oscar Salvador
2024-05-27 13:30 ` [RFC PATCH v4 16/16] mm: Remove CONFIG_ARCH_HAS_HUGEPD Christophe Leroy
2024-05-29 10:13   ` Oscar Salvador
2024-05-29 20:49   ` Oscar Salvador
2024-05-29 10:23 ` [RFC PATCH v4 00/16] Reimplement huge pages without hugepd on powerpc (8xx, e500, book3s/64) 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=Zlb0BugOwko4PrLm@localhost.localdomain \
    --to=osalvador@suse.com \
    --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