diff options
author | NeilBrown <neilb@suse.de> | 2019-09-20 08:36:45 +0200 |
---|---|---|
committer | J. Bruce Fields <bfields@redhat.com> | 2019-09-20 18:31:51 +0200 |
commit | 2030ca560c5f24138c1f0f8c8a89f1ac3b560613 (patch) | |
tree | e2a65bd95be1d38a8255e174221714a6c3a1a051 /fs/bad_inode.c | |
parent | nfsd: handle drc over-allocation gracefully. (diff) | |
download | linux-2030ca560c5f24138c1f0f8c8a89f1ac3b560613.tar.xz linux-2030ca560c5f24138c1f0f8c8a89f1ac3b560613.zip |
nfsd: degraded slot-count more gracefully as allocation nears exhaustion.
This original code in nfsd4_get_drc_mem() would hand out 30
slots (approximately NFSD_MAX_MEM_PER_SESSION bytes at slightly
over 2K per slot) to each requesting client until it ran out
of space, then it would possibly give one last client a reduced
allocation, then fail the allocation.
Since commit de766e570413 ("nfsd: give out fewer session slots as
limit approaches") the last 90 slots to be given to about 12
clients with quickly reducing slot counts (better than just 3
clients). This still seems unnecessarily hasty.
A subsequent patch allows over-allocation so every client gets
at least one slot, but that might be a bit restrictive.
The requested number of nfsd threads is the best guide we have to the
expected number of clients, so use that - if it is at least 8.
256 threads on a 256Meg machine - which is a lot for a tiny machine -
would result in nfsd_drc_max_mem being 2Meg, so 8K (3 slots) would be
available for the first client, and over 200 clients would get more
than 1 slot. So I don't think this change will be too debilitating on
poorly configured machines, though it does mean that a sensible
configuration is a little more important.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs/bad_inode.c')
0 files changed, 0 insertions, 0 deletions