linux-kernel - Re: [PATCH] mm/vmalloc: map contiguous pages in batches for vmap() whenever possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7f9fa27e-261f-4416-9a64-414d8130e5cb@kernel.org>
Date: Wed, 14 Jan 2026 13:59:43 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Barry Song <21cnbao@...il.com>, Uladzislau Rezki <urezki@...il.com>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
 dri-devel@...ts.freedesktop.org, jstultz@...gle.com,
 linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, Barry Song <v-songbaohua@...o.com>,
 Sumit Semwal <sumit.semwal@...aro.org>, Maxime Ripard <mripard@...nel.org>,
 Tangquan Zheng <zhengtangquan@...o.com>
Subject: Re: [PATCH] mm/vmalloc: map contiguous pages in batches for vmap()
 whenever possible

On 12/18/25 21:05, Barry Song wrote:
> [...]
>>>
>>> +static inline int get_vmap_batch_order(struct page **pages,
>>> +             unsigned int stride, unsigned int max_steps, unsigned int idx)
>>> +{
>>> +     int nr_pages = 1;
>>> +
>>> +     /*
>>> +      * Currently, batching is only supported in vmap_pages_range
>>> +      * when page_shift == PAGE_SHIFT.
>>> +      */
>>> +     if (stride != 1)
>>> +             return 0;
>>> +
>>> +     nr_pages = compound_nr(pages[idx]);
>>> +     if (nr_pages == 1)
>>> +             return 0;
>>> +     if (max_steps < nr_pages)
>>> +             return 0;
>>> +
>>> +     if (num_pages_contiguous(&pages[idx], nr_pages) == nr_pages)
>>> +             return compound_order(pages[idx]);
>>> +     return 0;
>>> +}
>>> +
>> Can we instead look at this as: it can be that we have continues
>> set of pages let's find out. I mean if we do not stick just to
>> compound pages.
> 
> We use PageCompound(pages[0]) and compound_nr() as quick
> filters to skip checking the contiguous count, and this is
> now the intended use case. Always checking contiguity might
> cause a slight regression, I guess.
> 
> BTW, do we have a strong use case where GFP_COMP or folio is
> not used, yet the pages are physically contiguous?

It usually happens by accident :)

E.g., allocate 2 pages and because we had to split an order-1 page into 
two order-0 pages, we get both of them.

Using num_pages_contiguous() only might indeed be nicer, but then we 
have to add some handling for getting aligned ranges (start and size 
aligned to order) ... so not sure if that is worth it.

-- 
Cheers

David