From: Petr Tesarik <ptesarik@suse.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: Zhaoyang Huang <huangzhaoyang@gmail.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
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: Tue, 14 Oct 2025 17:10:03 +0200 [thread overview]
Message-ID: <20251014171003.57bbfd63@mordecai.tesarici.cz> (raw)
In-Reply-To: <ecba7133-699c-4f3e-927c-bad5bd4c36a3@amd.com>
On Tue, 14 Oct 2025 15:04:14 +0200
Christian König <christian.koenig@amd.com> wrote:
> On 14.10.25 14:44, Zhaoyang Huang wrote:
> > On Tue, Oct 14, 2025 at 7:59 PM Christian König
> > <christian.koenig@amd.com> wrote:
> >>
> >> On 14.10.25 10:32, zhaoyang.huang wrote:
> >>> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >>>
> >>> The size of once dma-buf allocation could be dozens MB or much more
> >>> which introduce a loop of allocating several thousands of order-0 pages.
> >>> Furthermore, the concurrent allocation could have dma-buf allocation enter
> >>> direct-reclaim during the loop. This commit would like to eliminate the
> >>> above two affections by introducing alloc_pages_bulk_list in dma-buf's
> >>> order-0 allocation. This patch is proved to be conditionally helpful
> >>> in 18MB allocation as decreasing the time from 24604us to 6555us and no
> >>> harm when bulk allocation can't be done(fallback to single page
> >>> allocation)
> >>
> >> Well that sounds like an absolutely horrible idea.
> >>
> >> See the handling of allocating only from specific order is *exactly* there to avoid the behavior of bulk allocation.
> >>
> >> What you seem to do with this patch here is to add on top of the behavior to avoid allocating large chunks from the buddy the behavior to allocate large chunks from the buddy because that is faster.
> > emm, this patch doesn't change order-8 and order-4's allocation
> > behaviour but just to replace the loop of order-0 allocations into
> > once bulk allocation in the fallback way. What is your concern about
> > this?
>
> As far as I know the bulk allocation favors splitting large pages into smaller ones instead of allocating smaller pages first. That's where the performance benefit comes from.
>
> But that is exactly what we try to avoid here by allocating only certain order of pages.
This is a good question, actually. Yes, bulk alloc will split large
pages if there are insufficient pages on the pcp free list. But is
dma-buf indeed trying to avoid it, or is it merely using an inefficient
API? And does it need the extra speed? Even if it leads to increased
fragmentation?
Petr T
next prev parent reply other threads:[~2025-10-14 15:10 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 [this message]
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
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=20251014171003.57bbfd63@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=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