Re: [RFC PATCH 0/3] Introduce a bulk order-0 page allocator for sunrpc
From: Chuck Lever
Date: Wed Feb 24 2021 - 09:44:40 EST
>
On Feb 24, 2021, at 5:26 AM, Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx> wrote:
>
>
This is a prototype series that introduces a bulk order-0 page allocator
>
with sunrpc being the first user. The implementation is not particularly
>
efficient and the intention is to iron out what the semantics of the API
>
should be. That said, sunrpc was reported to have reduced allocation
>
latency when refilling a pool.
>
>
As a side-note, while the implementation could be more efficient, it
>
would require fairly deep surgery in numerous places. The lock scope would
>
need to be significantly reduced, particularly as vmstat, per-cpu and the
>
buddy allocator have different locking protocol that overal -- e.g. all
>
partially depend on irqs being disabled at various points. Secondly,
>
the core of the allocator deals with single pages where as both the bulk
>
allocator and per-cpu allocator operate in batches. All of that has to
>
be reconciled with all the existing users and their constraints (memory
>
offline, CMA and cpusets being the trickiest).
>
>
In terms of semantics required by new users, my preference is that a pair
>
of patches be applied -- the first which adds the required semantic to
>
the bulk allocator and the second which adds the new user.
>
>
Patch 1 of this series is a cleanup to sunrpc, it could be merged
>
separately but is included here for convenience.
>
>
Patch 2 is the prototype bulk allocator
>
>
Patch 3 is the sunrpc user. Chuck also has a patch which further caches
>
pages but is not included in this series. It's not directly
>
related to the bulk allocator and as it caches pages, it might
>
have other concerns (e.g. does it need a shrinker?)
>
>
This has only been lightly tested on a low-end NFS server. It did not break
>
but would benefit from an evaluation to see how much, if any, the headline
>
performance changes. The biggest concern is that a light test case showed
>
that there are a *lot* of bulk requests for 1 page which gets delegated to
>
the normal allocator. The same criteria should apply to any other users.
>
>
include/linux/gfp.h | 13 +++++
>
mm/page_alloc.c | 113 +++++++++++++++++++++++++++++++++++++++++-
>
net/sunrpc/svc_xprt.c | 47 ++++++++++++------
>
3 files changed, 157 insertions(+), 16 deletions(-)
Hi Mel-
Thank you for carrying the torch!
--
Chuck Lever