All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mike Galbraith <umgwanakikbuti@gmail.com>
Subject: Re: [PATCH] SUNRPC: Don't disable preemption while calling svc_pool_for_cpu().
Date: Tue, 10 May 2022 14:02:14 +0200	[thread overview]
Message-ID: <YnpURpp14qNi7TnI@linutronix.de> (raw)
In-Reply-To: <11F8D1AE-EB3D-48F0-A586-563165640AB8@oracle.com>

On 2022-05-09 16:56:47 [+0000], Chuck Lever III wrote:
> Hi Sebastian-
Hi Chuck,

> > On May 4, 2022, at 1:24 PM, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > 
> > svc_xprt_enqueue() disables preemption via get_cpu() and then asks for a
> > pool of a specific CPU (current) via svc_pool_for_cpu().
> > With disabled preemption it acquires svc_pool::sp_lock, a spinlock_t,
> > which is a sleeping lock on PREEMPT_RT and can't be acquired with
> > disabled preemption.
> 
> I found this paragraph a little unclear. If you repost, I'd suggest:
> 
>     svc_xprt_enqueue() disables preemption via get_cpu() and then asks
>     for a pool of a specific CPU (current) via svc_pool_for_cpu().
>     While preemption is disabled, svc_xprt_enqueue() acquires
>     svc_pool::sp_lock with bottom-halfs disabled, which can sleep on
>     PREEMPT_RT.

Sure.

> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index 5b59e2103526e..79965deec5b12 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -461,8 +460,7 @@ void svc_xprt_enqueue(struct svc_xprt *xprt)
> > 	if (test_and_set_bit(XPT_BUSY, &xprt->xpt_flags))
> > 		return;
> > 
> > -	cpu = get_cpu();
> > -	pool = svc_pool_for_cpu(xprt->xpt_server, cpu);
> > +	pool = svc_pool_for_cpu(xprt->xpt_server, raw_smp_processor_id());
> 
> The pre-2014 code here was this:
> 
> 	cpu = get_cpu();
> 	pool = svc_pool_for_cpu(xprt->xpt_server, cpu);
> 	put_cpu();
> 
> Your explanation covers the rationale for leaving pre-emption
> enabled in the body of svc_xprt_enqueue(), but it's not clear
> to me that rationale also applies to svc_pool_for_cpu().

I don't see why svc_pool_for_cpu() should be protected by disabling
preemption. It returns a "struct svc_pool" depending on the CPU number.
In the SVC_POOL_PERNODE case it will return the same pointer/ struct for
two different CPUs which belong to the same node.

> Protecting the svc_pool data structures with RCU might be
> better, but would amount to a more extensive change. To address
> the pre-emption issue quickly, you could simply revert this
> call site back to its pre-2014 form and postpone deeper changes.

You mean before commit
   983c684466e02 ("SUNRPC: get rid of the request wait queue")

I'm not sure how RCU would help here. It would ensure that the pool does
not vanish within the RCU section. The pool remains around until
svc_destroy() and I assume that everything pool related (like
svc_pool::sp_sockets) is gone by then.

> I have an NFS server in my lab on NUMA hardware and can run
> some tests this week with this patch.

I'm a little confused now. I could repost the patch with an updated
description as you suggested _or_ limit the get_cpu()/preempt-disabled
section to be only around svc_pool_for_cpu(). I don't see the reason for
it but will do as requested (if you want me to) since it doesn't cause
any problems.

Sebastian

  reply	other threads:[~2022-05-10 12:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04 17:24 [PATCH] SUNRPC: Don't disable preemption while calling svc_pool_for_cpu() Sebastian Andrzej Siewior
2022-05-05  3:19 ` Chuck Lever III
2022-05-05  6:26   ` Sebastian Andrzej Siewior
2022-05-09 16:56 ` Chuck Lever III
2022-05-10 12:02   ` Sebastian Andrzej Siewior [this message]
2022-05-10 13:38     ` Chuck Lever III
2022-05-10 14:38       ` [PATCH v2] " Sebastian Andrzej Siewior
2022-05-10 15:43         ` Chuck Lever III

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=YnpURpp14qNi7TnI@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=anna@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=trond.myklebust@hammerspace.com \
    --cc=umgwanakikbuti@gmail.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 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.