From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Joel Fernandes <joelaf@google.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: rcu-bh design
Date: Fri, 4 May 2018 10:32:06 -0700 [thread overview]
Message-ID: <20180504173205.GQ26088@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180504123050.2841f80d@gandalf.local.home>
On Fri, May 04, 2018 at 12:30:50PM -0400, Steven Rostedt wrote:
> On Fri, 04 May 2018 16:20:11 +0000
> Joel Fernandes <joelaf@google.com> wrote:
>
> > Hi Paul, everyone,
> >
> > I had some question(s) about rcu-bh design.
> > I am trying to understand the reasoning or need of it. I see that rcu-bh
> > will disable softirqs across read-side sections. But I am wondering why
> > this is needed. __do_softirq already disables softirq when a softirq
> > handler is running. The only reason I can see is, rcu-bh helps in
> > situations where - a softirq interrupts a preemptible RCU read-section and
> > prevents that read section from completing. But this problem would happen
> > if anyone where to use rcu-preempt - then does rcu-preempt even make sense
> > to use and shouldn't everyone be using rcu-bh?
>
> I thought rcu-bh uses softirqs as a quiescent state. Thus, blocking
> softirqs from happening makes sense. I don't think an
> rcu_read_lock_bh() makes sense in a softirq.
Agreed, any place in the code where bottom halves are enabled is an RCU-bh
quiescent state.
> > The other usecase for rcu-bh seems to be if context-switch is used as a
> > quiescent state, then softirq flood can prevent that from happening and
> > cause rcu grace periods from completing.
>
> > But preemptible RCU *does not* use context-switch as a quiescent state.
>
> It doesn't?
It does, but only sort of.
A context switch really is always an RCU-preempt quiescent state from
the perspective of the CPU. However, from the perspective of the task,
context switch is a quiescent state only if the task is not in an
RCU-preempt read-side critical section at the time.
> > So in that case rcu-bh would make
> > sense only in a configuration where we're not using preemptible-rcu at all
> > and are getting flooded by softirqs. Is that the reason rcu-bh needs to
> > exist?
>
> Maybe I'm confused by what you are asking.
The existence and use of RCU-bh in no way degrades the preemptibility of
RCU-preempt read-side critical sections. The reason is that RCU-bh and
RCU-preempt are completely separate, represented by different rcu_state
structure instances.
Thanx, Paul
next prev parent reply other threads:[~2018-05-04 17:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-04 16:20 rcu-bh design Joel Fernandes
2018-05-04 16:30 ` Steven Rostedt
2018-05-04 17:15 ` Joel Fernandes
2018-05-04 17:43 ` Paul E. McKenney
2018-05-04 18:34 ` Joel Fernandes
2018-05-04 18:49 ` Paul E. McKenney
2018-05-04 19:57 ` Joel Fernandes
2018-05-04 20:11 ` Paul E. McKenney
2018-05-04 20:33 ` Joel Fernandes
2018-05-04 22:49 ` Paul E. McKenney
2018-05-04 23:20 ` Joel Fernandes
2018-05-04 23:43 ` Paul E. McKenney
2018-05-05 0:39 ` Joel Fernandes
2018-05-04 17:32 ` Paul E. McKenney [this message]
2018-05-04 17:37 ` Steven Rostedt
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=20180504173205.GQ26088@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=joelaf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.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.