[PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory

[Wen Jiang]

On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm at linux-foundation.org> wrote:
>
> On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi at gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous. Two techniques are used:
>
> Thanks.
>
> > 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.
> >
> > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > CONT-PTE regions instead of just one.
> >
> > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> >
> > Patch 4 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().
> >
> > Patches 5-6 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.53us)
> > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
>
> Nice.
>
> > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
>
> Indeed.
>
> I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> folks) have time to go through this.
>
> Is there any effect on anything other than arm64?  I'm wondering how
> much testing these changes will really get in mm.git and linux-next.
>
> How is our selftests coverage of these changes?  Is there some existing
> selftest which will exercise these new features?
>

Hi Andrew,

I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
x86_64, comparing base (v7.0.10) against the patched kernel.

All test_vmalloc subtests passed on both platforms. I do not see any
functional or performance regression. The small differences below look
like measurement noise.

ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
5 runs averaged):

 +------------------------------+------------+------------+--------+
 | Test                         | Base(usec) |Patch(usec) | Change |
 +------------------------------+------------+------------+--------+
 | fix_size_alloc_test          |     935371 |     913368 |  -2.4% |
 | full_fit_alloc_test          |    1208295 |    1244718 |  +3.0% |
 | long_busy_list_alloc_test    |   35669866 |   35854584 |  +0.5% |
 | random_size_alloc_test       |   20122611 |   20200013 |  +0.4% |
 | fix_align_alloc_test         |    3240373 |    3288431 |  +1.5% |
 | random_size_align_alloc_test |    4822107 |    4792305 |  -0.6% |
 | pcpu_alloc_test              |      87641 |      89429 |  +2.0% |
 | Total cycles                 | 1586173575 | 1593193228 |  +0.4% |
 +------------------------------+------------+------------+--------+

x86_64 (Intel i7-8700, bare metal, pinned to CPU 0, performance governor,
5 runs averaged):

 +------------------------------+-------------+-------------+--------+
 | Test                         |  Base(usec) | Patch(usec) | Change |
 +------------------------------+-------------+-------------+--------+
 | fix_size_alloc_test          |      447739 |      439655 |  -1.8% |
 | full_fit_alloc_test          |      572719 |      575582 |  +0.5% |
 | long_busy_list_alloc_test    |     8544326 |     8635052 |  +1.1% |
 | random_size_alloc_test       |     4475421 |     4490037 |  +0.3% |
 | fix_align_alloc_test         |     1725389 |     1712483 |  -0.7% |
 | random_size_align_alloc_test |     2192646 |     2215064 |  +1.0% |
 | pcpu_alloc_test              |       50354 |       51911 |  +3.1% |
 | Total cycles                 | 57494755150 | 57703906913 |  +0.4% |
 +------------------------------+-------------+-------------+--------+

> You diligently went through the Sashiko report against v3 (thanks).
> Please pass an eye across its v4 report, see if something new popped
> up?
>         https://sashiko.dev/#/patchset/20260618084726.1070022-1-jiangwen6@xiaomi.com
>

I've gone through the Sashiko findings:

- Patch 5 (CONFIG_HAVE_ARCH_HUGE_VMAP): Over-interpretation.
  CONFIG_HAVE_ARCH_HUGE_VMAP is correct — it gates
  arch_vmap_pmd_supported() and arch_vmap_pte_supported_shift() which
  this code calls.

- Patch 5 (__ffs(page_to_pfn())): Over-interpretation. Never appears.

- Patch 6 (GFP_KERNEL triggering reclaim on alignment failure):
  Over-interpretation. The same GFP_KERNEL is used by the
  existing get_vm_area_caller() — no behavioral change.

Best Regards,
Wen