From: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
To: Wen Jiang <jiangwenxiaomi@gmail.com>,
akpm@linux-foundation.org, catalin.marinas@arm.com,
linux-mm@kvack.org, urezki@gmail.com, will@kernel.org
Cc: Xueyuan.chen21@gmail.com, ajd@linux.ibm.com,
anshuman.khandual@arm.com, baohua@kernel.org, david@kernel.org,
dev.jain@arm.com, jiangwen6@xiaomi.com, leo.yan@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
rppt@kernel.org, ryan.roberts@arm.com
Subject: Re: [PATCH v8 00/10] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
Date: Thu, 17 Sep 2026 14:17:40 +0200 [thread overview]
Message-ID: <493ef264-eab3-4be3-a80e-357f01ae1b37@kernel.org> (raw)
In-Reply-To: <20260917052933.188679-1-jiangwenxiaomi@gmail.com>
Hi,
Le 17/09/2026 à 07:29, Wen Jiang a écrit :
> From: Wen Jiang <jiangwen6@xiaomi.com>
>
> This patchset accelerates ioremap, vmalloc, and vmap when the memory is
> physically fully or partially contiguous. Two techniques are used:
>
> 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> segments
> 2. Use batched mappings wherever possible in both vmalloc and ARM64
> layers
>
> Besides accelerating the mapping path, this also enables large
> mappings (PMD and cont-PTE) for vmap, which are currently not
> supported.
This series doesn't apply. I tried to apply it on top of v7.2, v7.3-rc3
and next-20260916
Can you tell how to apply it ?
$ LANG= b4 shazam -l 20260917052933.188679-3-jiangwenxiaomi@gmail.com
Grabbing thread from
lore.kernel.org/all/20260917052933.188679-3-jiangwenxiaomi@gmail.com/t.mbox.gz
Checking for newer revisions
Grabbing search results from lore.kernel.org
Analyzing 11 messages in the thread
Analyzing 41 code-review messages
Checking attestation on all messages, may take a moment...
---
✓ [PATCH v8 1/10] arm64/mm: add pte_set_huge() and pte_clear_huge()
+ Link:
https://lore.kernel.org/r/20260917052933.188679-2-jiangwenxiaomi@gmail.com
✓ [PATCH v8 2/10] powerpc/8xx: add pte_set_huge()
+ Link:
https://lore.kernel.org/r/20260917052933.188679-3-jiangwenxiaomi@gmail.com
✓ [PATCH v8 3/10] mm/vmalloc: use pte_set_huge()/pte_clear_huge() for
PTE-level block mappings
+ Link:
https://lore.kernel.org/r/20260917052933.188679-4-jiangwenxiaomi@gmail.com
✓ [PATCH v8 4/10] arm64/hugetlb: drop the init_mm special case in
clear_flush()
+ Link:
https://lore.kernel.org/r/20260917052933.188679-5-jiangwenxiaomi@gmail.com
✓ [PATCH v8 5/10] arm64/vmalloc: allow arch_vmap_pte_range_map_size()
to batch multiple CONT_PTE
+ Link:
https://lore.kernel.org/r/20260917052933.188679-6-jiangwenxiaomi@gmail.com
✓ [PATCH v8 6/10] mm/vmalloc: extract vmap_set_ptes() to consolidate
PTE mapping logic
+ Link:
https://lore.kernel.org/r/20260917052933.188679-7-jiangwenxiaomi@gmail.com
✓ [PATCH v8 7/10] mm/vmalloc: extend page table walk to support
larger page_shift sizes and eliminate page table rewalk
+ Link:
https://lore.kernel.org/r/20260917052933.188679-8-jiangwenxiaomi@gmail.com
✓ [PATCH v8 8/10] mm/vmalloc: extract vm_shift() to consolidate
mapping shift selection
+ Link:
https://lore.kernel.org/r/20260917052933.188679-9-jiangwenxiaomi@gmail.com
✓ [PATCH v8 9/10] mm/vmalloc: map contiguous pages in batches for
vmap() if possible
+ Link:
https://lore.kernel.org/r/20260917052933.188679-10-jiangwenxiaomi@gmail.com
✓ [PATCH v8 10/10] mm/vmalloc: align vm_area so vmap() can batch mappings
+ Link:
https://lore.kernel.org/r/20260917052933.188679-11-jiangwenxiaomi@gmail.com
---
✓ Signed: DKIM/gmail.com
---
Total patches: 10
---
NOTE: some trailers ignored due to from/email mismatches:
! Trailer: Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Msg From: Barry Song <baohua@kernel.org>
NOTE: Rerun with -S to apply them anyway
---
Applying: arm64/mm: add pte_set_huge() and pte_clear_huge()
Patch failed at 0001 arm64/mm: add pte_set_huge() and pte_clear_huge()
error: patch failed: arch/arm64/mm/mmu.c:1872
error: arch/arm64/mm/mmu.c: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am
--abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Thanks
Christophe
>
> Patches 1-4 decouple the PTE-level block mapping path from HugeTLB.
> Previously vmap_pte_range() installed cont-PTE mappings by reusing
> set_huge_pte_at() and huge_ptep_get_and_clear(), which are HugeTLB
> helpers gated by CONFIG_HUGETLB_PAGE. This made the feature silently
> unavailable on CONFIG_HUGETLB_PAGE=n kernels, and coupled mm/vmalloc.c
> to HugeTLB internals. Patches 1 and 2 add the arm64 and powerpc/8xx
> implementations of pte_set_huge()/pte_clear_huge(), which join the
> existing pmd/pud_set_huge() family. Patch 3 adds the generic fallbacks
> and converts mm/vmalloc.c over. Patch 4 then removes the now-dead
> init_mm special case from arm64's clear_flush().
>
> Patch 5 extends ARM64 arch_vmap_pte_range_map_size() to batch multiple
> CONT_PTE blocks in one call instead of one at a time.
>
> Patch 6 extracts a common helper vmap_set_ptes() that consolidates PTE
> mapping logic for the ioremap and vmalloc/vmap paths, handling both
> CONT_PTE and regular PTE mappings. This prepares for the next patch.
>
> Patch 7 extends the page table walk path to support page shifts other
> than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> mappings. The function is renamed from vmap_small_pages_range_noflush()
> to vmap_pages_range_noflush_walk().
>
> Patch 8 extracts vm_shift() to consolidate vmalloc mapping shift
> selection for reuse in the batching path.
>
> Patches 9-10 add huge vmap support for contiguous pages, including
> support for non-compound pages with pfn alignment verification.
>
> On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> the performance CPUfreq policy enabled, benchmark results:
>
> * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> * vmalloc(1 MB) mapping time (excluding allocation) with
> VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53 us)
> * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
>
> Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
>
> Large vmap() mappings were also tested by Leo Yan with ARM trace buffer
> units, including TRBE and SPE. These units use the CPU page tables for
> address translation when writing trace data to DRAM, so using larger
> vmap() mapping granules can reduce TLB pressure on the trace writer.
>
> The TRBE test used a 1G CoreSight ETM AUX buffer. Across five runs on an
> isolated CPU, the average results were:
>
> * dtlb_walk: 68.4 -> 59.4 (-13.16%)
> * l1d_tlb_refill: 155.8 -> 119.6 (-23.23%)
> * l2d_tlb_refill: 161435.8 -> 495.0 (-99.69%)
>
> The SPE test used a 512M ARM SPE AUX buffer. Across five runs on an
> isolated CPU, the average results were:
>
> * dtlb_walk: 1710.4 -> 1315.6 (-23.08%)
> * l1d_tlb_refill: 16000.0 -> 15950.2 (-0.31%)
> * l2d_tlb_refill: 4796.0 -> 2931.2 (-38.88%)
>
> These results show that enabling larger vmap() mappings can materially
> reduce page table walks and TLB refills for large trace buffers.
>
> Many thanks to Leo Yan for his testing efforts on ARM trace buffers.
>
> Changes since v7:
> - v7's patch 1 (which extended the hugetlb helpers in
> arch/arm64/mm/hugetlbpage.c) is replaced by pte_set_huge()/
> pte_clear_huge(), split across patches 1-3 so that the arm64,
> powerpc/8xx and generic changes can be reviewed and acked
> independently: patch 1 is arm64 only, patch 2 is powerpc/8xx only,
> patch 3 is the generic fallbacks plus the mm/vmalloc.c conversion.
> hugetlbpage.c no longer gains the CONT_PTE batching hooks, and patch 4
> additionally removes its now-dead init_mm special case. mm/vmalloc.c
> no longer includes <linux/hugetlb.h>.
> - The generic pte_set_huge()/pte_clear_huge() fallbacks WARN_ON_ONCE()
> instead of silently doing nothing. They only exist to keep the build
> working on architectures without PTE-level block mappings, where they
> are unreachable (patch 3).
> - Patch 5 (v7 patch 2): use round_down(size, CONT_PTE_SIZE) instead of
> rounddown_pow_of_two(size), since pte_set_huge() takes the size directly
> without an ilog2() roundtrip. This lets a single call span several
> CONT_PTE blocks: a 768K (512K + 256K) ioremap is now 1.25x faster than
> v7.
> - Patch 6 (v7 patch 3): vmap_set_ptes() now calls pte_set_huge() instead
> of the hugetlb path.
> - Patch 9 (v7 patch 6): get_vmap_batch_order() takes pages+i instead of a
> separate idx argument, and applies pfn alignment limit to scan length
> rather than to the resulting order. Renamed idx/map_addr to
> batch_idx/batch_start. Dropped Dev's Reviewed-by.
>
> Changes since v6:
> - Add a clarifying comment about the reuse of hugetlb helpers
> by non-hugetlbfs(vmalloc) mm code (patch 1)
> - Expand the arm64/vmalloc commit message and comment to clarify that
> multi-CONT_PTE_SIZE values are vmalloc mapping spans, not HugeTLB
> hstate sizes (patch 2)
> - Move the local steps variable change in vmap_pte_range() into the
> vmap_set_ptes() extraction patch (patch 3)
> - Propagate vmap_pages_pte_range() errors through the upper
> vmap_pages_*() levels instead of returning -ENOMEM for all failures
> (patch 4)
> - Add a preparatory vm_shift() helper patch before the batching patch
> (patch 5)
> - Guard the PFN alignment clamp in get_vmap_batch_order() against PFN 0
> before calling __ffs() (patch 6)
> - Fix kmsan_vmap_pages_range_noflush() indentation in the batching path
> (patch 6)
>
> Changes since v5:
> - No code changes.
> - Pick up Reviewed-by and Tested-by tags from Dev, Leo and Uladzislau.
> Many thanks!
> - Add TRBE/SPE large vmap() test results from Leo Yan to the cover
> letter.
>
> Changes since v4:
> - Move pgsize update before contig_ptes check (patch 1)
> - Use rounddown_pow_of_two instead of __fls in
> arch_vmap_pte_range_map_size (patch 2)
> - Reword comment to avoid mentioning cont_pte and remove if in
> vmap_set_ptes (patch 3)
> - Rename vmap_batched() to vmap_pages_range_batched() (patch 5)
> - Use batch_end as the batching cursor to avoid an unused start variable
> (patch 5)
> - Check arch_vmap_pmd_supported before PMD mapping (patch 6)
>
> Changes since v3:
> - Squash vmap_pte_range() loop variable fix into patch 4 (patch 3, 4)
> - Use shift >= PMD_SHIFT and fix *nr increment in
> vmap_pages_pmd_range() (patch 4)
> - Pass page_shift directly without capping at PMD_SHIFT (patch 4, 5)
> - Add vm_shift() helper and pass pgprot_t to get_vmap_batch_order()
> (patch 5)
> - Use min(order, __ffs(pfn)) for graceful pfn alignment degradation,
> replacing IS_ALIGNED check (patch 5)
> - Remove irrelevant ioremap_max_page_shift early-exit (patch 5)
> - Add __get_vm_area_node_aligned_caller() wrapper, rename to
> vmap_get_aligned_vm_area() (patch 6)
>
> Changes since v2:
> - Use __fls instead of fls in arch_vmap_pte_range_map_size (patch 2)
> - Add WARN_ON checks in vmap_pages_pmd_range (patch 4)
> - Fix flush_cache_vmap to use saved start address instead of the
> already-advanced addr (patch 5)
> - Rename __vmap_huge() to vmap_batched() (patch 5)
> - Add caller parameter and unroll while(1) loop (patch 5)
> - Squash patch 7 into patch 5 (stop scanning for compound pages after
> encountering small pages)
>
> Changes since v1:
> - Fix condition order and use PMD_SIZE instead of CONT_PMD_SIZE in
> patch 1 (Dev Jain)
> - Squash patch 3+4 and patch 5+7 (Dev Jain)
> - Replace "zigzag" with "page table rewalk" in commit messages
> (Dev Jain)
> - Rename vmap_small_pages_range_noflush() to
> vmap_pages_range_noflush_walk() (Dev Jain)
> - Extract vmap_set_ptes() as a new patch to consolidate PTE mapping
> logic between vmap_pte_range() and vmap_pages_pte_range(), handling
> both CONT_PTE and regular mappings (Mike Rapoport)
> - Support non-compound pages in get_vmap_batch_order() by falling
> back to physical contiguity scanning with pfn alignment check
> (Dev Jain, Uladzislau Rezki)
> - In get_vmap_batch_order(), filter out orders that the architecture
> cannot batch by checking arch_vmap_pte_supported_shift() directly.
> This avoids overhead for orders 1-3 on ARM64 CONT_PTE with 4K
> pages. (patch 5)
>
> Barry Song (Xiaomi) (4):
> arm64/vmalloc: allow arch_vmap_pte_range_map_size() to batch multiple
> CONT_PTE
> mm/vmalloc: extend page table walk to support larger page_shift sizes
> and eliminate page table rewalk
> mm/vmalloc: map contiguous pages in batches for vmap() if possible
> mm/vmalloc: align vm_area so vmap() can batch mappings
>
> Wen Jiang (6):
> arm64/mm: add pte_set_huge() and pte_clear_huge()
> powerpc/8xx: add pte_set_huge()
> mm/vmalloc: use pte_set_huge()/pte_clear_huge() for PTE-level block
> mappings
> arm64/hugetlb: drop the init_mm special case in clear_flush()
> mm/vmalloc: extract vmap_set_ptes() to consolidate PTE mapping logic
> mm/vmalloc: extract vm_shift() to consolidate mapping shift selection
>
> arch/arm64/include/asm/pgtable.h | 6 +
> arch/arm64/include/asm/vmalloc.h | 8 +-
> arch/arm64/mm/hugetlbpage.c | 5 +-
> arch/arm64/mm/mmu.c | 19 ++
> arch/powerpc/include/asm/nohash/32/pte-8xx.h | 4 +
> arch/powerpc/mm/nohash/8xx.c | 29 ++
> include/linux/pgtable.h | 29 ++
> mm/vmalloc.c | 268 ++++++++++++++-----
> 8 files changed, 300 insertions(+), 68 deletions(-)
>
next prev parent reply other threads:[~2026-09-17 12:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 5:29 Wen Jiang
2026-09-17 5:29 ` [PATCH v8 01/10] arm64/mm: add pte_set_huge() and pte_clear_huge() Wen Jiang
2026-09-17 23:22 ` Barry Song
2026-09-17 5:29 ` [PATCH v8 02/10] powerpc/8xx: add pte_set_huge() Wen Jiang
2026-09-17 23:28 ` Barry Song
2026-09-17 5:29 ` [PATCH v8 03/10] mm/vmalloc: use pte_set_huge()/pte_clear_huge() for PTE-level block mappings Wen Jiang
2026-09-17 14:00 ` Christophe Leroy (CS GROUP)
2026-09-17 14:40 ` Wen Jiang
2026-09-17 21:44 ` Barry Song
2026-09-17 5:29 ` [PATCH v8 04/10] arm64/hugetlb: drop the init_mm special case in clear_flush() Wen Jiang
2026-09-17 5:29 ` [PATCH v8 05/10] arm64/vmalloc: allow arch_vmap_pte_range_map_size() to batch multiple CONT_PTE Wen Jiang
2026-09-17 5:29 ` [PATCH v8 06/10] mm/vmalloc: extract vmap_set_ptes() to consolidate PTE mapping logic Wen Jiang
2026-09-17 5:29 ` [PATCH v8 07/10] mm/vmalloc: extend page table walk to support larger page_shift sizes and eliminate page table rewalk Wen Jiang
2026-09-17 5:29 ` [PATCH v8 08/10] mm/vmalloc: extract vm_shift() to consolidate mapping shift selection Wen Jiang
2026-09-17 5:29 ` [PATCH v8 09/10] mm/vmalloc: map contiguous pages in batches for vmap() if possible Wen Jiang
2026-09-17 5:29 ` [PATCH v8 10/10] mm/vmalloc: align vm_area so vmap() can batch mappings Wen Jiang
2026-09-17 12:17 ` Christophe Leroy (CS GROUP) [this message]
2026-09-17 13:55 ` [PATCH v8 00/10] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory Christophe Leroy (CS GROUP)
2026-09-17 14:30 ` Wen Jiang
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=493ef264-eab3-4be3-a80e-357f01ae1b37@kernel.org \
--to=chleroy@kernel.org \
--cc=Xueyuan.chen21@gmail.com \
--cc=ajd@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=baohua@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=jiangwen6@xiaomi.com \
--cc=jiangwenxiaomi@gmail.com \
--cc=leo.yan@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
/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
all inboxes | Powered by JetHome®