From: Petr Tesarik <ptesarik@suse.com>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: "Matthew Wilcox" <willy@infradead.org>,
"Christian König" <christian.koenig@amd.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@redhat.com>,
"Mel Gorman" <mgorman@techsingularity.net>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T . J . Mercier" <tjmercier@google.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, steve.kang@unisoc.com
Subject: Re: [PATCH 2/2] driver: dma-buf: use alloc_pages_bulk_list for order-0 allocation
Date: Wed, 15 Oct 2025 10:40:08 +0200 [thread overview]
Message-ID: <20251015104008.4bcd99e7@mordecai.tesarici.cz> (raw)
In-Reply-To: <CAGWkznFG2_WGmLRmHnjV-49iTX0mrt9jxQBzZYK=K9U7eKJD0g@mail.gmail.com>
On Wed, 15 Oct 2025 13:52:57 +0800
Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
> On Wed, Oct 15, 2025 at 11:21 AM Matthew Wilcox <willy@infradead.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
next prev parent reply other threads:[~2025-10-15 8:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 8:32 [PATCH 0/2] optimization of dma-buf system_heap allocation zhaoyang.huang
2025-10-14 8:32 ` [PATCH 1/2] mm: call back alloc_pages_bulk_list since it is useful zhaoyang.huang
2025-10-14 9:41 ` Petr Tesarik
2025-10-14 12:46 ` Zhaoyang Huang
2025-10-15 12:16 ` David Hildenbrand
2025-10-15 12:35 ` Zhaoyang Huang
2025-10-14 8:32 ` [PATCH 2/2] driver: dma-buf: use alloc_pages_bulk_list for order-0 allocation zhaoyang.huang
2025-10-14 11:59 ` Christian König
2025-10-14 12:44 ` Zhaoyang Huang
2025-10-14 13:04 ` Christian König
2025-10-14 15:10 ` Petr Tesarik
2025-10-14 15:52 ` Christian König
2025-10-15 1:12 ` Zhaoyang Huang
2025-10-15 3:21 ` Matthew Wilcox
2025-10-15 5:52 ` Zhaoyang Huang
2025-10-15 8:40 ` Petr Tesarik [this message]
2025-10-15 9:14 ` Zhaoyang Huang
2025-10-14 12:45 ` Petr Tesarik
2025-10-14 14:06 ` [PATCH 0/2] optimization of dma-buf system_heap allocation Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251015104008.4bcd99e7@mordecai.tesarici.cz \
--to=ptesarik@suse.com \
--cc=Brian.Starkey@arm.com \
--cc=akpm@linux-foundation.org \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=david@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=huangzhaoyang@gmail.com \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=steve.kang@unisoc.com \
--cc=sumit.semwal@linaro.org \
--cc=surenb@google.com \
--cc=tjmercier@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=zhaoyang.huang@unisoc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox