From: NeilBrown <neilb@suse.de>
To: Chuck Lever <chuck.lever@oracle.com>, Jeff Layton <jlayton@kernel.org>
Cc: linux-nfs@vger.kernel.org, Olga Kornievskaia <kolga@netapp.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Steve Dickson <steved@redhat.com>
Subject: [PATCH 00/14 RFC] support automatic changes to nfsd thread count
Date: Mon, 15 Jul 2024 17:14:13 +1000 [thread overview]
Message-ID: <20240715074657.18174-1-neilb@suse.de> (raw)
This patch set (against nfsd-next) enables automatic adjustment of the
number of nfsd threads. The number can increase under high load, and
reduce after idle periods.
The first few patches (1-6) are cleanups that may not be entirely
relevant to the current series. They could safely land any time and
only need minimal review.
Patch 9,10,11 remove some places were sv_nrthreads are used for things
other than counting threads. It is use to adjust other limits. At the
time this seemed like an easy and sensible solution. I now have to
repent of that short-cut and find a better way to impose reasonable
limits.
These and the other sundry patches (7,8,12) can, I think safely land
whenever that get sufficient review. I think they are sensible even if
we won't end up adjusting threads dynamically.
Patches 13 and 14 build on all this to provide the desired
functionality. Patch 13 allows the maximum to be configured, and patch
14 starts or stops threads based on some simple triggers.
For 13 I decided that if the user/admin makes no explicit configuration,
then the currently request number of threads becomes a minimum, and a
maximum is determined based on the amount of memory. This will make
the patch set immediately useful but shouldn't unduly impact existing
configurations.
For patch 14 I only implemented starting a thread when there is work to
do but no threads to do it, and stopping a thread when it has been idle
for 5 seconds. The start-up is deliberately serialised so at least one
NFS request is serviced between the decision to start a thread and the
action of starting it. This hopefully encourages a ramping up of thread
count rather than a sudden jump.
There is certain room for discussion around the wisdom of these
heuristics, and what other heuristics are needed - we probably want a
shrinker to impose memory pressure of the number of threads. We
probably want a thread to exit rather than retry when a memory
allocation in svc_alloc_arg() fails.
I certainly wouldn't recommend patch 14 landing in any hurry at all.
I'd love to hear what y'all think, and what experiences you have when
testing it.
Thanks,
NeilBrown
next reply other threads:[~2024-07-15 7:47 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-15 7:14 NeilBrown [this message]
2024-07-15 7:14 ` [PATCH 01/14] lockd: discard nlmsvc_timeout NeilBrown
2024-07-15 7:14 ` [PATCH 02/14] SUNRPC: make various functions static, or not exported NeilBrown
2024-07-15 7:14 ` [PATCH 03/14] nfsd: move nfsd_pool_stats_open into nfsctl.c NeilBrown
2024-07-15 7:14 ` [PATCH 04/14] nfsd: don't allocate the versions array NeilBrown
2024-08-02 21:34 ` Mike Snitzer
2024-08-02 23:04 ` NeilBrown
2024-08-05 4:55 ` NeilBrown
2024-07-15 7:14 ` [PATCH 05/14] sunrpc: change sp_nrthreads from atomic_t to unsigned int NeilBrown
2024-07-15 14:12 ` Jeff Layton
2024-07-15 14:33 ` Jeff Layton
2024-07-16 1:33 ` NeilBrown
2024-07-24 19:36 ` Chuck Lever
2024-07-15 7:14 ` [PATCH 06/14] sunrpc: don't take ->sv_lock when updating ->sv_nrthreads NeilBrown
2024-07-15 7:14 ` [PATCH 07/14] Change unshare_fs_struct() to never fail NeilBrown
2024-07-15 14:39 ` Jeff Layton
2024-07-16 1:48 ` NeilBrown
2024-07-15 7:14 ` [PATCH 08/14] SUNRPC: move nrthreads counting to start/stop threads NeilBrown
2024-07-15 7:14 ` [PATCH 09/14] nfsd: return hard failure for OP_SETCLIENTID when there are too many clients NeilBrown
2024-07-15 15:21 ` Jeff Layton
2024-07-15 7:14 ` [PATCH 10/14] nfs: dynamically adjust per-client DRC slot limits NeilBrown
2024-07-15 7:14 ` [PATCH 11/14] nfsd: don't use sv_nrthreads in connection limiting calculations NeilBrown
2024-07-15 15:52 ` Jeff Layton
2024-07-16 2:04 ` NeilBrown
2024-07-15 7:14 ` [PATCH 12/14] sunrpc: introduce possibility that requested number of threads is different from actual NeilBrown
2024-07-15 16:00 ` Jeff Layton
2024-07-15 7:14 ` [PATCH 13/14] nfsd: introduce concept of a maximum number of threads NeilBrown
2024-07-15 17:06 ` Jeff Layton
2024-07-16 3:21 ` NeilBrown
2024-07-16 11:00 ` Jeff Layton
2024-07-16 13:31 ` Chuck Lever III
2024-07-16 18:49 ` Tom Talpey
2024-07-17 15:24 ` Chuck Lever III
2024-07-15 7:14 ` [PATCH 14/14] nfsd: adjust number of running nfsd threads NeilBrown
2024-07-15 17:29 ` [PATCH 00/14 RFC] support automatic changes to nfsd thread count Jeff Layton
2024-07-24 19:43 ` Chuck Lever III
2024-07-24 21:25 ` NeilBrown
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=20240715074657.18174-1-neilb@suse.de \
--to=neilb@suse.de \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=kolga@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@redhat.com \
--cc=tom@talpey.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