On Tue, 10 Nov 2026 at 01:24, Andrew Morton <[email protected]> wrote: > > On Mon, 9 Nov 2026 14:02:06 +0000 Leo Yan <[email protected]> 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. >
Right. I've posted a fixup for [07/10] in reply to that patch, switching the index to unsigned long. > : 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. > The nr_contig < 2 check is redundant, as noted. It's just a cheap early exit for the single-page case, so I'd lean towards keeping it, Thanks, Wen
