Messages in this thread | | | Date | Fri, 4 May 2018 12:30:50 -0400 | From | Steven Rostedt <> | Subject | Re: rcu-bh design |
| |
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.
> > 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?
> 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.
-- Steve
| |