Skip to content

Commit 3dfde97

Browse files
davidhildenbrandakpm00
authored andcommitted
mm: add get_and_clear_ptes() and clear_ptes()
Patch series "Optimizations for khugepaged", v4. If the underlying folio mapped by the ptes is large, we can process those ptes in a batch using folio_pte_batch(). For arm64 specifically, this results in a 16x reduction in the number of ptep_get() calls, since on a contig block, ptep_get() on arm64 will iterate through all 16 entries to collect a/d bits. Next, ptep_clear() will cause a TLBI for every contig block in the range via contpte_try_unfold(). Instead, use clear_ptes() to only do the TLBI at the first and last contig block of the range. For split folios, there will be no pte batching; the batch size returned by folio_pte_batch() will be 1. For pagetable split folios, the ptes will still point to the same large folio; for arm64, this results in the optimization described above, and for other arches, a minor improvement is expected due to a reduction in the number of function calls and batching atomic operations. This patch (of 3): Let's add variants to be used where "full" does not apply -- which will be the majority of cases in the future. "full" really only applies if we are about to tear down a full MM. Use get_and_clear_ptes() in existing code, clear_ptes() users will be added next. Link: https://lkml.kernel.org/r/20250724052301.23844-2-dev.jain@arm.com Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Dev Jain <dev.jain@arm.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Barry Song <baohua@kernel.org> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Mariano Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1 parent 1623717 commit 3dfde97

4 files changed

Lines changed: 48 additions & 3 deletions

File tree

arch/arm64/mm/mmu.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1528,7 +1528,7 @@ early_initcall(prevent_bootmem_remove_init);
15281528
pte_t modify_prot_start_ptes(struct vm_area_struct *vma, unsigned long addr,
15291529
pte_t *ptep, unsigned int nr)
15301530
{
1531-
pte_t pte = get_and_clear_full_ptes(vma->vm_mm, addr, ptep, nr, /* full = */ 0);
1531+
pte_t pte = get_and_clear_ptes(vma->vm_mm, addr, ptep, nr);
15321532

15331533
if (alternative_has_cap_unlikely(ARM64_WORKAROUND_2645198)) {
15341534
/*

include/linux/pgtable.h

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -736,6 +736,29 @@ static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm,
736736
}
737737
#endif
738738

739+
/**
740+
* get_and_clear_ptes - Clear present PTEs that map consecutive pages of
741+
* the same folio, collecting dirty/accessed bits.
742+
* @mm: Address space the pages are mapped into.
743+
* @addr: Address the first page is mapped at.
744+
* @ptep: Page table pointer for the first entry.
745+
* @nr: Number of entries to clear.
746+
*
747+
* Use this instead of get_and_clear_full_ptes() if it is known that we don't
748+
* need to clear the full mm, which is mostly the case.
749+
*
750+
* Note that PTE bits in the PTE range besides the PFN can differ. For example,
751+
* some PTEs might be write-protected.
752+
*
753+
* Context: The caller holds the page table lock. The PTEs map consecutive
754+
* pages that belong to the same folio. The PTEs are all in the same PMD.
755+
*/
756+
static inline pte_t get_and_clear_ptes(struct mm_struct *mm, unsigned long addr,
757+
pte_t *ptep, unsigned int nr)
758+
{
759+
return get_and_clear_full_ptes(mm, addr, ptep, nr, 0);
760+
}
761+
739762
#ifndef clear_full_ptes
740763
/**
741764
* clear_full_ptes - Clear present PTEs that map consecutive pages of the same
@@ -768,6 +791,28 @@ static inline void clear_full_ptes(struct mm_struct *mm, unsigned long addr,
768791
}
769792
#endif
770793

794+
/**
795+
* clear_ptes - Clear present PTEs that map consecutive pages of the same folio.
796+
* @mm: Address space the pages are mapped into.
797+
* @addr: Address the first page is mapped at.
798+
* @ptep: Page table pointer for the first entry.
799+
* @nr: Number of entries to clear.
800+
*
801+
* Use this instead of clear_full_ptes() if it is known that we don't need to
802+
* clear the full mm, which is mostly the case.
803+
*
804+
* Note that PTE bits in the PTE range besides the PFN can differ. For example,
805+
* some PTEs might be write-protected.
806+
*
807+
* Context: The caller holds the page table lock. The PTEs map consecutive
808+
* pages that belong to the same folio. The PTEs are all in the same PMD.
809+
*/
810+
static inline void clear_ptes(struct mm_struct *mm, unsigned long addr,
811+
pte_t *ptep, unsigned int nr)
812+
{
813+
clear_full_ptes(mm, addr, ptep, nr, 0);
814+
}
815+
771816
/*
772817
* If two threads concurrently fault at the same page, the thread that
773818
* won the race updates the PTE and its local TLB/Cache. The other thread

mm/mremap.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -280,7 +280,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
280280
old_pte, max_nr_ptes);
281281
force_flush = true;
282282
}
283-
pte = get_and_clear_full_ptes(mm, old_addr, old_ptep, nr_ptes, 0);
283+
pte = get_and_clear_ptes(mm, old_addr, old_ptep, nr_ptes);
284284
pte = move_pte(pte, old_addr, new_addr);
285285
pte = move_soft_dirty_pte(pte);
286286

mm/rmap.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2036,7 +2036,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
20362036
flush_cache_range(vma, address, end_addr);
20372037

20382038
/* Nuke the page table entry. */
2039-
pteval = get_and_clear_full_ptes(mm, address, pvmw.pte, nr_pages, 0);
2039+
pteval = get_and_clear_ptes(mm, address, pvmw.pte, nr_pages);
20402040
/*
20412041
* We clear the PTE but do not flush so potentially
20422042
* a remote CPU could still be writing to the folio.

0 commit comments

Comments
 (0)