From: Matthew Wilcox <willy@infradead.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chuck Lever <chuck.lever@oracle.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
Ilias Apalodimas <ilias.apalodimas@linaro.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>
Subject: Re: [PATCH 0/9 v6] Introduce a bulk order-0 page allocator with two in-tree users
Date: Thu, 25 Mar 2021 12:50:01 +0000 [thread overview]
Message-ID: <20210325125001.GW1719932@casper.infradead.org> (raw)
In-Reply-To: <20210325114228.27719-1-mgorman@techsingularity.net>
On Thu, Mar 25, 2021 at 11:42:19AM +0000, Mel Gorman wrote:
> This series introduces a bulk order-0 page allocator with sunrpc and
> the network page pool being the first users. The implementation is not
> efficient as semantics needed to be ironed out first. If no other semantic
> changes are needed, it can be made more efficient. Despite that, this
> is a performance-related for users that require multiple pages for an
> operation without multiple round-trips to the page allocator. Quoting
> the last patch for the high-speed networking use-case
>
> Kernel XDP stats CPU pps Delta
> Baseline XDP-RX CPU total 3,771,046 n/a
> List XDP-RX CPU total 3,940,242 +4.49%
> Array XDP-RX CPU total 4,249,224 +12.68%
>
> >From the SUNRPC traces of svc_alloc_arg()
>
> Single page: 25.007 us per call over 532,571 calls
> Bulk list: 6.258 us per call over 517,034 calls
> Bulk array: 4.590 us per call over 517,442 calls
>
> Both potential users in this series are corner cases (NFS and high-speed
> networks) so it is unlikely that most users will see any benefit in the
> short term. Other potential other users are batch allocations for page
> cache readahead, fault around and SLUB allocations when high-order pages
> are unavailable. It's unknown how much benefit would be seen by converting
> multiple page allocation calls to a single batch or what difference it may
> make to headline performance.
We have a third user, vmalloc(), with a 16% perf improvement. I know the
email says 21% but that includes the 5% improvement from switching to
kvmalloc() to allocate area->pages.
https://lore.kernel.org/linux-mm/20210323133948.GA10046@pc638.lan/
I don't know how many _frequent_ vmalloc users we have that will benefit
from this, but it's probably more than will benefit from improvements
to 200Gbit networking performance.
next prev parent reply other threads:[~2021-03-25 12:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-25 11:42 [PATCH 0/9 v6] Introduce a bulk order-0 page allocator with two in-tree users Mel Gorman
2021-03-25 11:42 ` [PATCH 1/9] mm/page_alloc: Rename alloced to allocated Mel Gorman
2021-03-25 11:59 ` Matthew Wilcox
2021-04-12 10:01 ` Vlastimil Babka
2021-03-25 11:42 ` [PATCH 2/9] mm/page_alloc: Add a bulk page allocator Mel Gorman
2021-03-25 12:05 ` Matthew Wilcox
2021-03-25 12:37 ` Mel Gorman
2021-04-12 10:21 ` Vlastimil Babka
2021-04-12 10:59 ` Mel Gorman
2021-04-12 11:19 ` Mel Gorman
2021-03-25 11:42 ` [PATCH 3/9] mm/page_alloc: Add an array-based interface to the " Mel Gorman
2021-04-12 10:36 ` Vlastimil Babka
2021-03-25 11:42 ` [PATCH 4/9] mm/page_alloc: optimize code layout for __alloc_pages_bulk Mel Gorman
2021-03-25 12:12 ` Matthew Wilcox
2021-03-25 12:40 ` Mel Gorman
2021-04-12 10:41 ` Vlastimil Babka
2021-03-25 11:42 ` [PATCH 5/9] mm/page_alloc: inline __rmqueue_pcplist Mel Gorman
2021-04-12 10:59 ` Vlastimil Babka
2021-03-25 11:42 ` [PATCH 6/9] SUNRPC: Set rq_page_end differently Mel Gorman
2021-03-25 11:42 ` [PATCH 7/9] SUNRPC: Refresh rq_pages using a bulk page allocator Mel Gorman
2021-03-25 11:42 ` [PATCH 8/9] net: page_pool: refactor dma_map into own function page_pool_dma_map Mel Gorman
2021-03-25 11:42 ` [PATCH 9/9] net: page_pool: use alloc_pages_bulk in refill code path Mel Gorman
2021-03-25 13:33 ` Alexander Lobakin
2021-03-25 12:50 ` Matthew Wilcox [this message]
2021-03-25 13:25 ` [PATCH 0/9 v6] Introduce a bulk order-0 page allocator with two in-tree users Mel Gorman
2021-03-25 14:06 ` Uladzislau Rezki
2021-03-25 14:09 ` Matthew Wilcox
2021-03-25 14:13 ` Uladzislau Rezki
2021-03-25 14:26 ` Mel Gorman
2021-03-25 14:46 ` Uladzislau Rezki
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=20210325125001.GW1719932@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=brouer@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=hch@infradead.org \
--cc=ilias.apalodimas@linaro.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 \
/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.