On Wed, 15 Oct 2025 13:52:57 +0800 Zhaoyang Huang <[email protected]> wrote:
> On Wed, Oct 15, 2025 at 11:21 AM Matthew Wilcox <[email protected]> wrote: > > > > On Wed, Oct 15, 2025 at 09:12:07AM +0800, Zhaoyang Huang wrote: > > > > Could be that we need to make this behavior conditional, but somebody > > > > would need to come up with some really good arguments to justify the > > > > complexity. > > > ok, should we use CONFIG_DMA_BUF_BULK_ALLOCATION or a variable > > > controlled by sysfs interface? > > > > No. Explain what you're trying to solve, because you haven't yet. > Dma-buf works as a memory allocation backend could loop thousands of > times alloc_pages for allocating order-0 pages to fulfill the dozens > MB demand, this commit would like to replace the loop by once > alloc_pages_bulk. Whereas, alloc_pages_bulk_array perhaps introduces > extra memory allocation along with direct-reclaim which could be more > expensive than iterating the list. so call back the API > alloc_pages_bulk_list as well This does not quite explain it. IIRC you mentioned allocating 18M as an example. The ideal outcome in that case is: - 16 order-8 compound pages - 32 order-4 compound pages -> total 48 calls to alloc_pages() But presumably, that's not what happens, because fragmentation makes (some of) those order-8 allocations fail. Since you talk about thousands of loop iterations, it looks like even order-4 allocation fail in your case. Then I agree there's not much value in trying to avoid further fragmentation, and after so many order-0 allocations, it's probably also pointless to do memory reclaim. OTOH I can see why the opposite approach is a bad idea in situations where fragmentation can be avoided. To make things even worse, alloc_pages_bulk() will rather split pages in the preferred zone than try allocating from the next best zone. To sum it up, Zhaoyang, can you please describe in more detail what happens in your scenario and what you believe should happen instead? Petr T
