Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Mike Owen <mjnowen@gmail.com>, Chuck Lever <cel@kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia	 <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nfsd: report the requested maximum number of threads instead of number running
Date: Thu, 05 Feb 2026 06:18:45 -0500	[thread overview]
Message-ID: <d0484cf69968e0415e4c0b9fca9217ebeca928e7.camel@kernel.org> (raw)
In-Reply-To: <6944906a-9256-4f10-88fa-822a639eb5eb@gmail.com>

You won't be able to get to the min-threads setting from /proc. That's
only available via netlink. If you enable dynamic threading (via
netlink), then the traditional "th" count in /proc currently shows you
the number of running threads. If this patch is applied, it'll show you
the requested maximum instead.

So, with this patch applied you can query both the min and max number
of threads via netlink. We don't yet have an interface to query the
number of threads currently running. In principle, you can get that
info from "ps", but we could add that to the netlink interface if
someone can make a good use-case for it.

-- Jeff

On Thu, 2026-02-05 at 10:01 +0000, Mike Owen wrote:
> Hi,
> I currently rely on: "/proc/net/rpc/nfsd" to retrieve the current number of threads via "th": https://svennd.be/nfsd-stats-explained-procnetrpcnfsd/
> After the various patches to introduce dynamic threading, where in the future, would a user retrieve the currently set min, max and actual running thread count reliably?
> Would be lovely if the man page indicated this.
> Thanks,
> Mike
> 
> On 04/02/2026 19:13, Jeff Layton wrote:
> > On Wed, 2026-02-04 at 13:51 -0500, Chuck Lever wrote:
> > > 
> > > On Wed, Feb 4, 2026, at 12:23 PM, Jeff Layton wrote:
> > > > The current netlink and /proc interfaces deviate from their traditional
> > > > values when dynamic threading is enabled, and there is currently no way
> > > > to know what the current setting is. This patch brings the reporting
> > > > back in line with traditional behavior.
> > > > 
> > > > Make these interfaces report the requested maximum number of threads
> > > > instead of the number currently running.
> > > > 
> > > > Fixes: d8316b837c2c ("nfsd: add controls to set the minimum number of 
> > > > threads per pool")
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > > I think this is less surprising than the current behavior of what's in
> > > > Chuck's tree. We could also consider adding netlink attributes to report
> > > > the number of running threads, but you can get that info from ps too.
> > > > ---
> > > >  fs/nfsd/nfsctl.c | 2 +-
> > > >  fs/nfsd/nfssvc.c | 7 ++++---
> > > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c
> > > > index 
> > > > 4d8e3c1a7be3b3a4e4f5248b27b60d6b3ae88d51..178c7646b2e25630b85de937d7ced18947c047f9 
> > > > 100644
> > > > --- a/fs/nfsd/nfsctl.c
> > > > +++ b/fs/nfsd/nfsctl.c
> > > > @@ -1700,7 +1700,7 @@ int nfsd_nl_threads_get_doit(struct sk_buff *skb, 
> > > > struct genl_info *info)
> > > >  			struct svc_pool *sp = &nn->nfsd_serv->sv_pools[i];
> > > > 
> > > >  			err = nla_put_u32(skb, NFSD_A_SERVER_THREADS,
> > > > -					  sp->sp_nrthreads);
> > > > +					  sp->sp_nrthrmax);
> > > >  			if (err)
> > > >  				goto err_unlock;
> > > >  		}
> > > > diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
> > > > index 
> > > > 8184514c58de8e396795cd4714a04d66d9637f17..be0add971c2d994948c3e8fca19bcf6f3c75dfaf 
> > > > 100644
> > > > --- a/fs/nfsd/nfssvc.c
> > > > +++ b/fs/nfsd/nfssvc.c
> > > > @@ -239,12 +239,13 @@ static void nfsd_net_free(struct percpu_ref *ref)
> > > > 
> > > >  int nfsd_nrthreads(struct net *net)
> > > >  {
> > > > -	int rv = 0;
> > > > +	int i, rv = 0;
> > > >  	struct nfsd_net *nn = net_generic(net, nfsd_net_id);
> > > > 
> > > >  	mutex_lock(&nfsd_mutex);
> > > >  	if (nn->nfsd_serv)
> > > > -		rv = nn->nfsd_serv->sv_nrthreads;
> > > > +		for (i = 0; i < nn->nfsd_serv->sv_nrpools; ++i)
> > > > +			rv += nn->nfsd_serv->sv_pools[i].sp_nrthrmax;
> > > >  	mutex_unlock(&nfsd_mutex);
> > > >  	return rv;
> > > >  }
> > > > @@ -673,7 +674,7 @@ int nfsd_get_nrthreads(int n, int *nthreads, struct 
> > > > net *net)
> > > > 
> > > >  	if (serv)
> > > >  		for (i = 0; i < serv->sv_nrpools && i < n; i++)
> > > > -			nthreads[i] = serv->sv_pools[i].sp_nrthreads;
> > > > +			nthreads[i] = serv->sv_pools[i].sp_nrthrmax;
> > > >  	return 0;
> > > >  }
> > > 
> > > AI code review observes that:
> > > 
> > > The documentation should be updated to reflect that these interfaces
> > > now report the configured maximum threads rather than running threads:
> > > 
> > > 1. Documentation/netlink/specs/nfsd.yaml line 168 - threads-get is
> > >    documented as "get the number of running threads" but now returns
> > >    the configured maximum
> > > 2. fs/nfsd/nfsctl.c lines 387-405 - The write_threads() docstring
> > >    says it reports "the number of running NFSD threads" but now
> > >    reports the configured maximum
> > > 3. fs/nfsd/nfsctl.c lines 1666-1673 - The nfsd_nl_threads_get_doit()
> > >    docstring says "get the number of running threads"
> > > 
> > 
> > Ok, I'll do that for v2.
> > 
> > Thanks,
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-02-05 11:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-04 17:23 [PATCH] nfsd: report the requested maximum number of threads instead of number running Jeff Layton
2026-02-04 18:51 ` Chuck Lever
2026-02-04 19:13   ` Jeff Layton
2026-02-05 10:01     ` Mike Owen
2026-02-05 11:18       ` Jeff Layton [this message]
2026-02-05 14:19         ` Chuck Lever

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=d0484cf69968e0415e4c0b9fca9217ebeca928e7.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=cel@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mjnowen@gmail.com \
    --cc=neil@brown.name \
    --cc=okorniev@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