All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: Chuck Lever <cel@kernel.org>
Cc: Anna Schumaker <anna.schumaker@oracle.com>,
	Trond Myklebust <trondmy@kernel.org>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/2] SUNRPC: Make rpciod and xprtiod visible in sysfs
Date: Fri, 13 Nov 2026 12:38:48 -0500	[thread overview]
Message-ID: <avdLKA6kYX_vFk4m@kernel.org> (raw)
In-Reply-To: <67be1870-8488-45f1-84e3-b047a75fa406@app.fastmail.com>

On Fri, Nov 13, 2026 at 09:18:36AM -0500, Chuck Lever wrote:
> 
> 
> On Thu, Nov 12, 2026, at 7:16 PM, Mike Snitzer wrote:
> > rpciod and xprtiod are unbound workqueues.  An async task's work is
> > queued to the affinity pod of the CPU that queues it, but an unbound
> > workqueue's affinity is not strict by default, so the scheduler is free
> > to run the worker on any CPU the workqueue allows.  On a two-node NFS
> > client whose writers are pinned to the node local to their NIC, with
> > the workqueues' affinity scope set to numa, 1.5% to 2.4% of the skbs
> > sent on each port were still handed to the driver from the other
> > node's CPUs: 97% of them from rpciod running rpc_async_schedule(), the
> > rest from xprtiod.
> >
> > Neither workqueue can be made strict today, because neither is created
> > with WQ_SYSFS and so neither has affinity_scope, affinity_strict or
> > cpumask under /sys/devices/virtual/workqueue/.  Add WQ_SYSFS to both.
> > Nothing changes until an administrator writes those attributes.
> >
> > With affinity_strict set to 1 on both, the same client sent nothing
> > from the other node and spent about 1.7 fewer CPUs at the same
> > throughput.
> >
> > Signed-off-by: Mike Snitzer <snitzer@kernel.org>
> > ---
> >  net/sunrpc/sched.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
> > index 016f16ca57799..83e2974a44d9f 100644
> > --- a/net/sunrpc/sched.c
> > +++ b/net/sunrpc/sched.c
> > @@ -1278,11 +1278,11 @@ static int rpciod_start(void)
> >  	/*
> >  	 * Create the rpciod thread and wait for it to start.
> >  	 */
> > -	wq = alloc_workqueue("rpciod", WQ_MEM_RECLAIM | WQ_UNBOUND, 0);
> > +	wq = alloc_workqueue("rpciod", WQ_MEM_RECLAIM | WQ_UNBOUND | WQ_SYSFS, 0);
> >  	if (!wq)
> >  		goto out_failed;
> >  	rpciod_workqueue = wq;
> > -	wq = alloc_workqueue("xprtiod", WQ_UNBOUND | WQ_MEM_RECLAIM, 0);
> > +	wq = alloc_workqueue("xprtiod", WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_SYSFS, 0);
> >  	if (!wq)
> >  		goto free_rpciod;
> >  	xprtiod_workqueue = wq;
> > -- 
> > 2.52.0
> 
> I already posted a patch for this back in September:
> 
> https://lore.kernel.org/linux-nfs/20260915-performance-v3-3-ae26d460bfd3@kernel.org/

Nice

> Did it get rejected?

Maybe it was overlooked, Anna?

  reply	other threads:[~2026-11-13 17:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13  0:16 [PATCH 0/2] SUNRPC: keep the client's sends on their node, and stop copying them Mike Snitzer
2026-11-13  0:16 ` [PATCH 1/2] SUNRPC: Make rpciod and xprtiod visible in sysfs Mike Snitzer
2026-11-13 14:18   ` Chuck Lever
2026-11-13 17:38     ` Mike Snitzer [this message]
2026-11-13  0:16 ` [PATCH 2/2] SUNRPC: Splice a request's pages into the TCP socket Mike Snitzer
2026-11-13 21:26   ` Anna Schumaker

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=avdLKA6kYX_vFk4m@kernel.org \
    --to=snitzer@kernel.org \
    --cc=anna.schumaker@oracle.com \
    --cc=cel@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.