linux-kernel - Re: [PATCH 2/2] driver: dma-buf: use alloc_pages_bulk

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251015104008.4bcd99e7@mordecai.tesarici.cz>
Date: Wed, 15 Oct 2025 10:40:08 +0200
From: Petr Tesarik <ptesarik@...e.com>
To: Zhaoyang Huang <huangzhaoyang@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>, Christian König
 <christian.koenig@....com>, Suren Baghdasaryan <surenb@...gle.com>,
 "zhaoyang.huang" <zhaoyang.huang@...soc.com>, Andrew Morton
 <akpm@...ux-foundation.org>, David Hildenbrand <david@...hat.com>, Mel
 Gorman <mgorman@...hsingularity.net>, Vlastimil Babka <vbabka@...e.cz>,
 Sumit Semwal <sumit.semwal@...aro.org>, Benjamin Gaignard
 <benjamin.gaignard@...labora.com>, Brian Starkey <Brian.Starkey@....com>,
 John Stultz <jstultz@...gle.com>, "T . J . Mercier" <tjmercier@...gle.com>,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, steve.kang@...soc.com
Subject: Re: [PATCH 2/2] driver: dma-buf: use alloc_pages_bulk_list for
 order-0 allocation

On Wed, 15 Oct 2025 13:52:57 +0800
Zhaoyang Huang <huangzhaoyang@...il.com> wrote:

> On Wed, Oct 15, 2025 at 11:21 AM Matthew Wilcox <willy@...radead.org> 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