Re: [PATCH v12 00/10] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 9 Nov 2026 14:02:06 +0000 Leo Yan <leo.yan@arm.com> wrote:

> On Mon, Nov 09, 2026 at 07:07:23PM +0800, Wen Jiang wrote:
> 
> [...]
> 
> > > Do we have sufficient ARM review?
> > >
> > 
> > Thanks for picking this up.
> > 
> > On ARM review: Dev reviewed the earlier revision in detail and
> > his suggestions are folded in. Leo Yan tested the large vmap() path
> > on TRBE/SPE. We'd welcome more ARM review from Ryan, Catalin
> > and others.
> 
> I confirmed that my Tested-by tag remains valid on the latest version.
> The improvement is consistent with L2D TLB refill reduced from
> ~16000+ to ~500+ across multiple runs.

Thanks.  I added your t-b to every patch in the mm.git copy of this
series.


AI review found a couple of little things:

: In [07/10], vmap_pages_range_noflush_walk() uses an int nr
: index, now shared by the high-order mapping path. The previous
: high-order path used unsigned int i, nr. Beyond INT_MAX base
: pages the new index overflows and pages[*nr] can go out of
: bounds. On x86-64/4K that means an allocation above 8 TiB,
: within the vmalloc VA window but requiring a very large machine.
: Please carry unsigned long or size_t through the direct walker.

The vmap(8TB) limit is already well known, not sure that we plan to do
anything about it(?).  But the patchset seems to drop that limit to 4TB
for higher-order pages, which can't be a good thing.

: In [09/10], nr_contig < 2 can be dropped: the loop guarantees
: at least one page, and vm_shift(..., PAGE_SIZE) returns zero
: for a single page. I withdraw my earlier NULL-page objection;
: I could not establish a legitimate producer of that input.