From: Paul Menzel <pmenzel@molgen.mpg.de>
To: "J. Bruce Fields" <bfields@redhat.com>, Jeff Layton <jlayton@kernel.org>
Cc: Chris Tracy <ctracy@engr.scu.edu>,
linux-nfs@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
it+linux-nfs@molgen.mpg.de
Subject: Regression caused by commit c54f24e3 (nfsd: fix performance-limiting session calculation)
Date: Tue, 2 Jul 2019 23:59:48 +0200 [thread overview]
Message-ID: <0b5fdd56-d570-c787-cd56-7e6d0ba65225@molgen.mpg.de> (raw)
In-Reply-To: <8c3e0249-b17f-4bd2-4a46-afd4d35f4763@molgen.mpg.de>
Dear Bruce,
Could it be that commit c54f24e3 (nfsd: fix performance-limiting session
calculation) causes a regression on big memory machines (1 TB)?
> From c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 Mon Sep 17 00:00:00 2001
> From: "J. Bruce Fields" <bfields@redhat.com>
> Date: Thu, 21 Feb 2019 10:47:00 -0500
> Subject: [PATCH] nfsd: fix performance-limiting session calculation
>
> We're unintentionally limiting the number of slots per nfsv4.1 session
> to 10. Often more than 10 simultaneous RPCs are needed for the best
> performance.
>
> This calculation was meant to prevent any one client from using up more
> than a third of the limit we set for total memory use across all clients
> and sessions. Instead, it's limiting the client to a third of the
> maximum for a single session.
>
> Fix this.
>
> Reported-by: Chris Tracy <ctracy@engr.scu.edu>
> Cc: stable@vger.kernel.org
> Fixes: de766e570413 "nfsd: give out fewer session slots as limit approaches"
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
> fs/nfsd/nfs4state.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index fb3c9844c82a..6a45fb00c5fc 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1544,16 +1544,16 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca)
> {
> u32 slotsize = slot_bytes(ca);
> u32 num = ca->maxreqs;
> - int avail;
> + unsigned long avail, total_avail;
>
> spin_lock(&nfsd_drc_lock);
> - avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION,
> - nfsd_drc_max_mem - nfsd_drc_mem_used);
> + total_avail = nfsd_drc_max_mem - nfsd_drc_mem_used;
> + avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION, total_avail);
> /*
> * Never use more than a third of the remaining memory,
> * unless it's the only way to give this client a slot:
> */
> - avail = clamp_t(int, avail, slotsize, avail/3);
> + avail = clamp_t(int, avail, slotsize, total_avail/3);
> num = min_t(int, num, avail / slotsize);
> nfsd_drc_mem_used += num * slotsize;
> spin_unlock(&nfsd_drc_lock);
Booting a 80 threads, 1 TB server with Linux 4.19.56 and Linux 5.2-rc7
causes connections problems for the clients. The problems do not happen
on servers with just 96 GB memory for example. Bisecting points to the
two commits below (and I can only continue tomorrow).
c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 (nfsd: fix performance-limiting
session calculation)
8127d82705998568b52ac724e28e00941538083d (NFS: Don't recoalesce on error
in nfs_pageio_complete_mirror())
If you have things I could do to verify this besides reverting it
tomorrow, please tell. It’d be great if it could be fixed before Linux
5.2 is released.
Kind regards,
Paul
next parent reply other threads:[~2019-07-03 1:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190702165107.93C8A2067CFDD@mx.molgen.mpg.de>
[not found] ` <8c3e0249-b17f-4bd2-4a46-afd4d35f4763@molgen.mpg.de>
2019-07-02 21:59 ` Paul Menzel [this message]
2019-07-03 9:56 ` Paul Menzel
2019-07-03 12:54 ` [PATCH] nfsd: Fix overflow causing non-working mounts on 1 TB machines Paul Menzel
2019-07-03 15:56 ` J. Bruce Fields
2019-07-03 16:03 ` Paul Menzel
2019-07-03 16:43 ` J. Bruce Fields
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=0b5fdd56-d570-c787-cd56-7e6d0ba65225@molgen.mpg.de \
--to=pmenzel@molgen.mpg.de \
--cc=bfields@redhat.com \
--cc=ctracy@engr.scu.edu \
--cc=it+linux-nfs@molgen.mpg.de \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®