+ arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

+ arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[Andrew Morton]

The patch titled
     Subject: arm64/mm: set_pte(): new layer to manage contig bit
has been added to the -mm mm-unstable branch.  Its filename is
     arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch

This patch will later appear in the mm-unstable branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days

------------------------------------------------------
From: Ryan Roberts <ryan.roberts@arm.com>
Subject: arm64/mm: set_pte(): new layer to manage contig bit
Date: Mon, 18 Dec 2023 10:50:48 +0000

Create a new layer for the in-table PTE manipulation APIs.  For now, The
existing API is prefixed with double underscore to become the arch-private
API and the public API is just a simple wrapper that calls the private
API.

The public API implementation will subsequently be used to transparently
manipulate the contiguous bit where appropriate.  But since there are
already some contig-aware users (e.g.  hugetlb, kernel mapper), we must
first ensure those users use the private API directly so that the future
contig-bit manipulations in the public API do not interfere with those
existing uses.

Link: https://lkml.kernel.org/r/20231218105100.172635-5-ryan.roberts@arm.com
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Tested-by: John Hubbard <jhubbard@nvidia.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Barry Song <21cnbao@gmail.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Yang Shi <shy828301@gmail.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/arm64/include/asm/pgtable.h |   12 ++++++++----
 arch/arm64/kernel/efi.c          |    2 +-
 arch/arm64/mm/fixmap.c           |    2 +-
 arch/arm64/mm/kasan_init.c       |    4 ++--
 arch/arm64/mm/mmu.c              |    2 +-
 arch/arm64/mm/pageattr.c         |    2 +-
 arch/arm64/mm/trans_pgd.c        |    4 ++--
 7 files changed, 16 insertions(+), 12 deletions(-)

--- a/arch/arm64/include/asm/pgtable.h~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/include/asm/pgtable.h
@@ -93,7 +93,8 @@ static inline pteval_t __phys_to_pte_val
 	__pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot))
 
 #define pte_none(pte)		(!pte_val(pte))
-#define pte_clear(mm,addr,ptep)	set_pte(ptep, __pte(0))
+#define pte_clear(mm, addr, ptep) \
+				__set_pte(ptep, __pte(0))
 #define pte_page(pte)		(pfn_to_page(pte_pfn(pte)))
 
 /*
@@ -261,7 +262,7 @@ static inline pte_t pte_mkdevmap(pte_t p
 	return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
 }
 
-static inline void set_pte(pte_t *ptep, pte_t pte)
+static inline void __set_pte(pte_t *ptep, pte_t pte)
 {
 	WRITE_ONCE(*ptep, pte);
 
@@ -350,7 +351,7 @@ static inline void set_ptes(struct mm_st
 
 	for (;;) {
 		__check_safe_pte_update(mm, ptep, pte);
-		set_pte(ptep, pte);
+		__set_pte(ptep, pte);
 		if (--nr == 0)
 			break;
 		ptep++;
@@ -534,7 +535,7 @@ static inline void __set_pte_at(struct m
 {
 	__sync_cache_and_tags(pte, nr);
 	__check_safe_pte_update(mm, ptep, pte);
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 }
 
 static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
@@ -1118,6 +1119,9 @@ extern pte_t ptep_modify_prot_start(stru
 extern void ptep_modify_prot_commit(struct vm_area_struct *vma,
 				    unsigned long addr, pte_t *ptep,
 				    pte_t old_pte, pte_t new_pte);
+
+#define set_pte					__set_pte
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_PGTABLE_H */
--- a/arch/arm64/kernel/efi.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/kernel/efi.c
@@ -111,7 +111,7 @@ static int __init set_permissions(pte_t
 		pte = set_pte_bit(pte, __pgprot(PTE_PXN));
 	else if (system_supports_bti_kernel() && spd->has_bti)
 		pte = set_pte_bit(pte, __pgprot(PTE_GP));
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
--- a/arch/arm64/mm/fixmap.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/mm/fixmap.c
@@ -121,7 +121,7 @@ void __set_fixmap(enum fixed_addresses i
 	ptep = fixmap_pte(addr);
 
 	if (pgprot_val(flags)) {
-		set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
+		__set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
 	} else {
 		pte_clear(&init_mm, addr, ptep);
 		flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
--- a/arch/arm64/mm/kasan_init.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/mm/kasan_init.c
@@ -112,7 +112,7 @@ static void __init kasan_pte_populate(pm
 		if (!early)
 			memset(__va(page_phys), KASAN_SHADOW_INIT, PAGE_SIZE);
 		next = addr + PAGE_SIZE;
-		set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(page_phys), PAGE_KERNEL));
 	} while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep)));
 }
 
@@ -266,7 +266,7 @@ static void __init kasan_init_shadow(voi
 	 * so we should make sure that it maps the zero page read-only.
 	 */
 	for (i = 0; i < PTRS_PER_PTE; i++)
-		set_pte(&kasan_early_shadow_pte[i],
+		__set_pte(&kasan_early_shadow_pte[i],
 			pfn_pte(sym_to_pfn(kasan_early_shadow_page),
 				PAGE_KERNEL_RO));
 
--- a/arch/arm64/mm/mmu.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/mm/mmu.c
@@ -178,7 +178,7 @@ static void init_pte(pmd_t *pmdp, unsign
 	do {
 		pte_t old_pte = READ_ONCE(*ptep);
 
-		set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+		__set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
 
 		/*
 		 * After the PTE entry has been populated once, we
--- a/arch/arm64/mm/pageattr.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/mm/pageattr.c
@@ -41,7 +41,7 @@ static int change_page_range(pte_t *ptep
 	pte = clear_pte_bit(pte, cdata->clear_mask);
 	pte = set_pte_bit(pte, cdata->set_mask);
 
-	set_pte(ptep, pte);
+	__set_pte(ptep, pte);
 	return 0;
 }
 
--- a/arch/arm64/mm/trans_pgd.c~arm64-mm-set_pte-new-layer-to-manage-contig-bit
+++ a/arch/arm64/mm/trans_pgd.c
@@ -41,7 +41,7 @@ static void _copy_pte(pte_t *dst_ptep, p
 		 * read only (code, rodata). Clear the RDONLY bit from
 		 * the temporary mappings we use during restore.
 		 */
-		set_pte(dst_ptep, pte_mkwrite_novma(pte));
+		__set_pte(dst_ptep, pte_mkwrite_novma(pte));
 	} else if ((debug_pagealloc_enabled() ||
 		   is_kfence_address((void *)addr)) && !pte_none(pte)) {
 		/*
@@ -55,7 +55,7 @@ static void _copy_pte(pte_t *dst_ptep, p
 		 */
 		BUG_ON(!pfn_valid(pte_pfn(pte)));
 
-		set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
+		__set_pte(dst_ptep, pte_mkpresent(pte_mkwrite_novma(pte)));
 	}
 }
 
_

Patches currently in -mm which might be from ryan.roberts@arm.com are

mm-allow-deferred-splitting-of-arbitrary-anon-large-folios.patch
mm-non-pmd-mappable-large-folios-for-folio_add_new_anon_rmap.patch
mm-thp-introduce-multi-size-thp-sysfs-interface.patch
mm-thp-introduce-multi-size-thp-sysfs-interface-fix.patch
mm-thp-support-allocation-of-anonymous-multi-size-thp.patch
mm-thp-support-allocation-of-anonymous-multi-size-thp-fix.patch
selftests-mm-kugepaged-restore-thp-settings-at-exit.patch
selftests-mm-factor-out-thp-settings-management.patch
selftests-mm-support-multi-size-thp-interface-in-thp_settings.patch
selftests-mm-khugepaged-enlighten-for-multi-size-thp.patch
selftests-mm-cow-generalize-do_run_with_thp-helper.patch
selftests-mm-cow-add-tests-for-anonymous-multi-size-thp.patch
mm-thp-batch-collapse-pmd-with-set_ptes.patch
mm-batch-copy-pte-ranges-during-fork.patch
mm-batch-clear-pte-ranges-during-zap_pte_range.patch
arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch
arm64-mm-set_ptes-set_pte_at-new-layer-to-manage-contig-bit.patch
arm64-mm-pte_clear-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_get_and_clear-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_test_and_clear_young-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_clear_flush_young-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_set_wrprotect-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_set_access_flags-new-layer-to-manage-contig-bit.patch
arm64-mm-ptep_get-new-layer-to-manage-contig-bit.patch
arm64-mm-split-__flush_tlb_range-to-elide-trailing-dsb.patch
arm64-mm-wire-up-pte_cont-for-user-mappings.patch
arm64-mm-implement-new-helpers-to-optimize-fork.patch
arm64-mm-implement-clear_ptes-to-optimize-exit-munmap-dontneed.patch
selftests-mm-log-run_vmtestssh-results-in-tap-format.patch

Re: + arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[Will Deacon]

On Mon, Dec 18, 2023 at 09:23:15AM -0800, Andrew Morton wrote:
> 
> The patch titled
>      Subject: arm64/mm: set_pte(): new layer to manage contig bit
> has been added to the -mm mm-unstable branch.  Its filename is
>      arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch
> 
> This patch will shortly appear at
>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch
> 
> This patch will later appear in the mm-unstable branch at
>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> 
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
> 
> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> 
> The -mm tree is included into linux-next via the mm-everything
> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> and is updated there every 2-3 working days
> 
> ------------------------------------------------------
> From: Ryan Roberts <ryan.roberts@arm.com>
> Subject: arm64/mm: set_pte(): new layer to manage contig bit
> Date: Mon, 18 Dec 2023 10:50:48 +0000
> 
> Create a new layer for the in-table PTE manipulation APIs.  For now, The
> existing API is prefixed with double underscore to become the arch-private
> API and the public API is just a simple wrapper that calls the private
> API.
> 
> The public API implementation will subsequently be used to transparently
> manipulate the contiguous bit where appropriate.  But since there are
> already some contig-aware users (e.g.  hugetlb, kernel mapper), we must
> first ensure those users use the private API directly so that the future
> contig-bit manipulations in the public API do not interfere with those
> existing uses.

Hmm, I certainly didn't have this series earmarked as v4.8 material. I
gave it a quick once-over last week but, with the looming holidays, I was
planning to come back to it properly in the New Year. I also thought ther
was a fork() regression that was under investigation?

Ryan -- what is your expectation here?

In any case, this series makes significant changes to the low-level
arm64 mm code and I don't think many of us will be around in the next
couple of weeks to deal with the fallout if it kicks up any issues.

Andrew -- if Ryan doesn't object, please can you drop this for now?

Cheers,

Will

Re: + arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[Ryan Roberts]

On 19/12/2023 10:10, Will Deacon wrote:
> On Mon, Dec 18, 2023 at 09:23:15AM -0800, Andrew Morton wrote:
>>
>> The patch titled
>>      Subject: arm64/mm: set_pte(): new layer to manage contig bit
>> has been added to the -mm mm-unstable branch.  Its filename is
>>      arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch
>>
>> This patch will shortly appear at
>>      https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch
>>
>> This patch will later appear in the mm-unstable branch at
>>     git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>>
>> Before you just go and hit "reply", please:
>>    a) Consider who else should be cc'ed
>>    b) Prefer to cc a suitable mailing list as well
>>    c) Ideally: find the original patch on the mailing list and do a
>>       reply-to-all to that, adding suitable additional cc's
>>
>> *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
>>
>> The -mm tree is included into linux-next via the mm-everything
>> branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>> and is updated there every 2-3 working days
>>
>> ------------------------------------------------------
>> From: Ryan Roberts <ryan.roberts@arm.com>
>> Subject: arm64/mm: set_pte(): new layer to manage contig bit
>> Date: Mon, 18 Dec 2023 10:50:48 +0000
>>
>> Create a new layer for the in-table PTE manipulation APIs.  For now, The
>> existing API is prefixed with double underscore to become the arch-private
>> API and the public API is just a simple wrapper that calls the private
>> API.
>>
>> The public API implementation will subsequently be used to transparently
>> manipulate the contiguous bit where appropriate.  But since there are
>> already some contig-aware users (e.g.  hugetlb, kernel mapper), we must
>> first ensure those users use the private API directly so that the future
>> contig-bit manipulations in the public API do not interfere with those
>> existing uses.
> 
> Hmm, I certainly didn't have this series earmarked as v4.8 material. I
> gave it a quick once-over last week but, with the looming holidays, I was
> planning to come back to it properly in the New Year. I also thought ther
> was a fork() regression that was under investigation?

I've fixed the fork regression - well mostly; it's now only a 2.6% regression
when ARM64_CONTPTE is enabled, but chatting with Catalin, we thought that may be
acceptable given the other performance benefits. We also couldn't identify any
real-world use cases where fork is the bottleneck (modern Android uses
pre-forked zygotes as I understand). I've posted a bunch of microbenchmark
results in the cover letter and commit logs.

> 
> Ryan -- what is your expectation here?

My original stated goal for v3 was to push and see if I could get it into v6.8,
but given I didn't get any offical review feedback from the key arm guys, and as
you say, I had a fork regression (now fixed), I assumed v4 would now be
targetting v6.9 at best. I also assumed it would go through the arm64 tree so
would be implicitly held until you/Catalin/Mark/... had reviewed it. It would be
nice to get some review and aim for v6.9 if possible. But I agree v6.8 is not
realistic at this point.

I guess I'm learning yet another process lesson here to be more explicit about
what I'd like to have done with my postings in the cover letter??

> 
> In any case, this series makes significant changes to the low-level
> arm64 mm code and I don't think many of us will be around in the next
> couple of weeks to deal with the fallout if it kicks up any issues.
> 
> Andrew -- if Ryan doesn't object, please can you drop this for now?

It's always nice to get linux-next soak time; Is there a middle ground where we
keep it in mm-unstable for a bit but don't progress it to mm-stable, and if
there are any arm64 bug reports we drop it? Or is that too complicated?

> 
> Cheers,
> 
> Will

Re: + arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[David Hildenbrand]

>> In any case, this series makes significant changes to the low-level
>> arm64 mm code and I don't think many of us will be around in the next
>> couple of weeks to deal with the fallout if it kicks up any issues.
>>
>> Andrew -- if Ryan doesn't object, please can you drop this for now?
> 
> It's always nice to get linux-next soak time; Is there a middle ground where we
> keep it in mm-unstable for a bit but don't progress it to mm-stable, and if
> there are any arm64 bug reports we drop it? Or is that too complicated?

If stuff is lurking too long in -next/mm-unstable, it might create 
conflicts with other patch sets that might go upstream / to mm-stable 
faster.

-- 
Cheers,

David / dhildenb

Re: + arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[Ryan Roberts]

On 19/12/2023 10:53, David Hildenbrand wrote:
>>> In any case, this series makes significant changes to the low-level
>>> arm64 mm code and I don't think many of us will be around in the next
>>> couple of weeks to deal with the fallout if it kicks up any issues.
>>>
>>> Andrew -- if Ryan doesn't object, please can you drop this for now?
>>
>> It's always nice to get linux-next soak time; Is there a middle ground where we
>> keep it in mm-unstable for a bit but don't progress it to mm-stable, and if
>> there are any arm64 bug reports we drop it? Or is that too complicated?
> 
> If stuff is lurking too long in -next/mm-unstable, it might create conflicts
> with other patch sets that might go upstream / to mm-stable faster.

Yeah fair enough (can't imagine what you might be thinking of :) ).

Let's drop it then.

> 

Re: + arm64-mm-set_pte-new-layer-to-manage-contig-bit.patch added to mm-unstable branch

[Andrew Morton]

On Tue, 19 Dec 2023 11:25:12 +0000 Ryan Roberts <ryan.roberts@arm.com> wrote:

> On 19/12/2023 10:53, David Hildenbrand wrote:
> >>> In any case, this series makes significant changes to the low-level
> >>> arm64 mm code and I don't think many of us will be around in the next
> >>> couple of weeks to deal with the fallout if it kicks up any issues.
> >>>
> >>> Andrew -- if Ryan doesn't object, please can you drop this for now?
> >>
> >> It's always nice to get linux-next soak time; Is there a middle ground where we
> >> keep it in mm-unstable for a bit but don't progress it to mm-stable, and if
> >> there are any arm64 bug reports we drop it? Or is that too complicated?
> > 
> > If stuff is lurking too long in -next/mm-unstable, it might create conflicts
> > with other patch sets that might go upstream / to mm-stable faster.
> 
> Yeah fair enough (can't imagine what you might be thinking of :) ).
> 
> Let's drop it then.

Gone, thanks.