From: Mel Gorman <mgorman@suse.de>
To: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Nicholas Piggin <npiggin@gmail.com>,
Hillf Danton <hdanton@sina.com>, Michal Hocko <mhocko@suse.com>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 2/3] mm/vmalloc: Switch to bulk allocator in __vmalloc_area_node()
Date: Mon, 17 May 2021 09:24:50 +0100 [thread overview]
Message-ID: <20210517082449.GT3672@suse.de> (raw)
In-Reply-To: <20210516202056.2120-3-urezki@gmail.com>
On Sun, May 16, 2021 at 10:20:55PM +0200, Uladzislau Rezki (Sony) wrote:
> Recently there has been introduced a page bulk allocator for
> users which need to get number of pages per one call request.
>
> For order-0 pages switch to an alloc_pages_bulk_array_node()
> instead of alloc_pages_node(), the reason is the former is
> not capable of allocating set of pages, thus a one call is
> per one page.
>
> Second, according to my tests the bulk allocator uses less
> cycles even for scenarios when only one page is requested.
> Running the "perf" on same test case shows below difference:
>
> <default>
> - 45.18% __vmalloc_node
> - __vmalloc_node_range
> - 35.60% __alloc_pages
> - get_page_from_freelist
> 3.36% __list_del_entry_valid
> 3.00% check_preemption_disabled
> 1.42% prep_new_page
> <default>
>
> <patch>
> - 31.00% __vmalloc_node
> - __vmalloc_node_range
> - 14.48% __alloc_pages_bulk
> 3.22% __list_del_entry_valid
> - 0.83% __alloc_pages
> get_page_from_freelist
> <patch>
>
> The "test_vmalloc.sh" also shows performance improvements:
>
> fix_size_alloc_test_4MB loops: 1000000 avg: 89105095 usec
> fix_size_alloc_test loops: 1000000 avg: 513672 usec
> full_fit_alloc_test loops: 1000000 avg: 748900 usec
> long_busy_list_alloc_test loops: 1000000 avg: 8043038 usec
> random_size_alloc_test loops: 1000000 avg: 4028582 usec
> fix_align_alloc_test loops: 1000000 avg: 1457671 usec
>
> fix_size_alloc_test_4MB loops: 1000000 avg: 62083711 usec
> fix_size_alloc_test loops: 1000000 avg: 449207 usec
> full_fit_alloc_test loops: 1000000 avg: 735985 usec
> long_busy_list_alloc_test loops: 1000000 avg: 5176052 usec
> random_size_alloc_test loops: 1000000 avg: 2589252 usec
> fix_align_alloc_test loops: 1000000 avg: 1365009 usec
>
> For example 4MB allocations illustrates ~30% gain, all the
> rest is also better.
>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
FWIW, it passed build and boot tests.
Acked-by: Mel Gorman <mgorman@suse.de>
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-05-17 8:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-16 20:20 [PATCH 0/3] vmalloc() vs bulk allocator v2 Uladzislau Rezki (Sony)
2021-05-16 20:20 ` [PATCH 1/3] mm/page_alloc: Add an alloc_pages_bulk_array_node() helper Uladzislau Rezki (Sony)
2021-05-16 20:20 ` [PATCH 2/3] mm/vmalloc: Switch to bulk allocator in __vmalloc_area_node() Uladzislau Rezki (Sony)
2021-05-17 8:24 ` Mel Gorman [this message]
2021-05-17 11:51 ` Uladzislau Rezki
2021-05-17 11:51 ` Uladzislau Rezki
2021-05-19 13:44 ` Christoph Hellwig
2021-05-19 14:39 ` Uladzislau Rezki
2021-05-19 15:56 ` Mel Gorman
2021-05-19 19:52 ` Uladzislau Rezki
2021-05-19 21:07 ` Uladzislau Rezki
2021-06-28 23:00 ` Andrew Morton
2021-05-16 20:20 ` [PATCH 3/3] mm/vmalloc: Print a warning message first on failure Uladzislau Rezki (Sony)
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=20210517082449.GT3672@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hdanton@sina.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=npiggin@gmail.com \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=rostedt@goodmis.org \
--cc=urezki@gmail.com \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.