From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Chuck Lever <chuck.lever@oracle.com>,
Christoph Hellwig <hch@infradead.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Matthew Wilcox <willy@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-Net <netdev@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
Linux-NFS <linux-nfs@vger.kernel.org>,
brouer@redhat.com
Subject: Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator
Date: Mon, 22 Mar 2021 13:04:46 +0100 [thread overview]
Message-ID: <20210322130446.0a505db0@carbon> (raw)
In-Reply-To: <20210322091845.16437-1-mgorman@techsingularity.net>
On Mon, 22 Mar 2021 09:18:42 +0000
Mel Gorman <mgorman@techsingularity.net> wrote:
> This series is based on top of Matthew Wilcox's series "Rationalise
> __alloc_pages wrapper" and does not apply to 5.12-rc2. If you want to
> test and are not using Andrew's tree as a baseline, I suggest using the
> following git tree
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git mm-bulk-rebase-v5r9
page_bench04_bulk[1] micro-benchmark on branch: mm-bulk-rebase-v5r9
[1] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/bench/page_bench04_bulk.c
BASELINE
single_page alloc+put: Per elem: 199 cycles(tsc) 55.472 ns
LIST variant: time_bulk_page_alloc_free_list: step=bulk size
Per elem: 206 cycles(tsc) 57.478 ns (step:1)
Per elem: 154 cycles(tsc) 42.861 ns (step:2)
Per elem: 145 cycles(tsc) 40.536 ns (step:3)
Per elem: 142 cycles(tsc) 39.477 ns (step:4)
Per elem: 142 cycles(tsc) 39.610 ns (step:8)
Per elem: 137 cycles(tsc) 38.155 ns (step:16)
Per elem: 135 cycles(tsc) 37.739 ns (step:32)
Per elem: 134 cycles(tsc) 37.282 ns (step:64)
Per elem: 133 cycles(tsc) 36.993 ns (step:128)
ARRAY variant: time_bulk_page_alloc_free_array: step=bulk size
Per elem: 202 cycles(tsc) 56.383 ns (step:1)
Per elem: 144 cycles(tsc) 40.047 ns (step:2)
Per elem: 134 cycles(tsc) 37.339 ns (step:3)
Per elem: 128 cycles(tsc) 35.578 ns (step:4)
Per elem: 120 cycles(tsc) 33.592 ns (step:8)
Per elem: 116 cycles(tsc) 32.362 ns (step:16)
Per elem: 113 cycles(tsc) 31.476 ns (step:32)
Per elem: 110 cycles(tsc) 30.633 ns (step:64)
Per elem: 110 cycles(tsc) 30.596 ns (step:128)
Compared to the previous results (see below) list-variant got faster,
but array-variant is still faster. The array variant lost a little
performance. I think this can be related to the stats counters got
added/moved inside the loop, in this patchset.
Previous results from:
https://lore.kernel.org/netdev/20210319181031.44dd3113@carbon/
On Fri, 19 Mar 2021 18:10:31 +0100 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> BASELINE
> single_page alloc+put: 207 cycles(tsc) 57.773 ns
>
> LIST variant: time_bulk_page_alloc_free_list: step=bulk size
>
> Per elem: 294 cycles(tsc) 81.866 ns (step:1)
> Per elem: 214 cycles(tsc) 59.477 ns (step:2)
> Per elem: 199 cycles(tsc) 55.504 ns (step:3)
> Per elem: 192 cycles(tsc) 53.489 ns (step:4)
> Per elem: 188 cycles(tsc) 52.456 ns (step:8)
> Per elem: 184 cycles(tsc) 51.346 ns (step:16)
> Per elem: 183 cycles(tsc) 50.883 ns (step:32)
> Per elem: 184 cycles(tsc) 51.236 ns (step:64)
> Per elem: 189 cycles(tsc) 52.620 ns (step:128)
>
> ARRAY variant: time_bulk_page_alloc_free_array: step=bulk size
>
> Per elem: 195 cycles(tsc) 54.174 ns (step:1)
> Per elem: 123 cycles(tsc) 34.224 ns (step:2)
> Per elem: 113 cycles(tsc) 31.430 ns (step:3)
> Per elem: 108 cycles(tsc) 30.003 ns (step:4)
> Per elem: 102 cycles(tsc) 28.417 ns (step:8)
> Per elem: 98 cycles(tsc) 27.475 ns (step:16)
> Per elem: 96 cycles(tsc) 26.901 ns (step:32)
> Per elem: 95 cycles(tsc) 26.487 ns (step:64)
> Per elem: 94 cycles(tsc) 26.170 ns (step:128)
> The users of the API have been dropped in this version as the callers
> need to check whether they prefer an array or list interface (whether
> preference is based on convenience or performance).
I'll start coding up the page_pool API user and benchmark that.
> Changelog since v4
> o Drop users of the API
> o Remove free_pages_bulk interface, no users
In [1] benchmark I just open-coded free_pages_bulk():
https://github.com/netoptimizer/prototype-kernel/commit/49d224b19850b767c
> o Add array interface
> o Allocate single page if watermark checks on local zones fail
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2021-03-22 12:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 9:18 [PATCH 0/3 v5] Introduce a bulk order-0 page allocator Mel Gorman
2021-03-22 9:18 ` [PATCH 1/3] mm/page_alloc: Rename alloced to allocated Mel Gorman
2021-03-22 9:18 ` [PATCH 2/3] mm/page_alloc: Add a bulk page allocator Mel Gorman
2021-03-23 16:00 ` Jesper Dangaard Brouer
2021-03-23 18:43 ` Mel Gorman
2021-03-22 9:18 ` [PATCH 3/3] mm/page_alloc: Add an array-based interface to the " Mel Gorman
2021-03-22 12:04 ` Jesper Dangaard Brouer [this message]
2021-03-22 16:44 ` [PATCH 0/3 v5] Introduce a bulk order-0 " Mel Gorman
2021-03-22 18:25 ` Chuck Lever III
2021-03-22 19:49 ` Mel Gorman
2021-03-22 20:32 ` Chuck Lever III
2021-03-22 20:58 ` Mel Gorman
2021-03-23 11:08 ` Jesper Dangaard Brouer
2021-03-23 14:45 ` Mel Gorman
2021-03-23 18:52 ` Chuck Lever III
2021-03-23 11:13 ` Matthew Wilcox
2021-03-23 10:44 ` Mel Gorman
2021-03-23 15:08 ` Jesper Dangaard Brouer
2021-03-23 16:29 ` Mel Gorman
2021-03-23 17:06 ` Jesper Dangaard Brouer
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=20210322130446.0a505db0@carbon \
--to=brouer@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=netdev@vger.kernel.org \
--cc=vbabka@suse.cz \
--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.