From: Petr Tesarik <ptesarik@suse.com>
To: "zhaoyang.huang" <zhaoyang.huang@unisoc.com>
Cc: "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>,
"Christian König" <christian.koenig@amd.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,
"Zhaoyang Huang" <huangzhaoyang@gmail.com>,
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 14:45:13 +0200 [thread overview]
Message-ID: <20251014144513.445a370d@mordecai.tesarici.cz> (raw)
In-Reply-To: <20251014083230.1181072-3-zhaoyang.huang@unisoc.com>
On Tue, 14 Oct 2025 16:32:30 +0800
"zhaoyang.huang" <zhaoyang.huang@unisoc.com> 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)
>
> Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> ---
> drivers/dma-buf/heaps/system_heap.c | 36 +++++++++++++++++++----------
> 1 file changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c
> index bbe7881f1360..71b028c63bd8 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -300,8 +300,8 @@ static const struct dma_buf_ops system_heap_buf_ops = {
> .release = system_heap_dma_buf_release,
> };
>
> -static struct page *alloc_largest_available(unsigned long size,
> - unsigned int max_order)
> +static void alloc_largest_available(unsigned long size,
> + unsigned int max_order, unsigned int *num_pages, struct list_head *list)
This interface feels weird. Maybe you could return the number of pages
instead of making this a void function and passing a pointer to get that
number?
> {
> struct page *page;
> int i;
> @@ -312,12 +312,19 @@ static struct page *alloc_largest_available(unsigned long size,
> if (max_order < orders[i])
> continue;
>
> - page = alloc_pages(order_flags[i], orders[i]);
> - if (!page)
> + if (orders[i]) {
> + page = alloc_pages(order_flags[i], orders[i]);
nitpick: Since the lowest order is special-cased now, you can simply
use HIGH_ORDER_GFP here and remove order_flags[] entirely.
> + if (page) {
> + list_add(&page->lru, list);
> + *num_pages = 1;
> + }
> + } else
> + *num_pages = alloc_pages_bulk_list(LOW_ORDER_GFP, size / PAGE_SIZE, list);
> +
> + if (list_empty(list))
> continue;
> - return page;
> + return;
> }
> - return NULL;
> }
>
> static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> @@ -335,6 +342,8 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> struct list_head pages;
> struct page *page, *tmp_page;
> int i, ret = -ENOMEM;
> + unsigned int num_pages;
> + LIST_HEAD(head);
>
> buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> if (!buffer)
> @@ -348,6 +357,8 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> INIT_LIST_HEAD(&pages);
> i = 0;
> while (size_remaining > 0) {
> + num_pages = 0;
> + INIT_LIST_HEAD(&head);
> /*
> * Avoid trying to allocate memory if the process
> * has been killed by SIGKILL
> @@ -357,14 +368,15 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> goto free_buffer;
> }
>
> - page = alloc_largest_available(size_remaining, max_order);
> - if (!page)
> + alloc_largest_available(size_remaining, max_order, &num_pages, &head);
> + if (!num_pages)
> goto free_buffer;
>
> - list_add_tail(&page->lru, &pages);
> - size_remaining -= page_size(page);
> - max_order = compound_order(page);
> - i++;
> + list_splice_tail(&head, &pages);
> + max_order = folio_order(lru_to_folio(&head));
> + size_remaining -= PAGE_SIZE * (num_pages << max_order);
This looks complicated. What about changing alloc_largest_available()
to return the total number of pages and using PAGE_SIZE * num_page?
Ah, you still have to look at the folio order to determine the new
value of max_order, so no big win. Hm. You could pass a pointer to
max_order down to alloc_largest_available(), but at that point I think
it's a matter of taste (aka bikeshedding).
Petr T
> + i += num_pages;
> +
> }
>
> table = &buffer->sg_table;
next prev parent reply other threads:[~2025-10-14 12:45 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
2025-10-15 9:14 ` Zhaoyang Huang
2025-10-14 12:45 ` Petr Tesarik [this message]
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=20251014144513.445a370d@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