On Fri, May 4, 2018 at 11:49 AM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: > On Fri, May 04, 2018 at 06:34:32PM +0000, Joel Fernandes wrote: >> On Fri, May 4, 2018 at 10:42 AM Paul E. McKenney >> <paul...@linux.vnet.ibm.com> >> wrote: >> [...] >> > > > > But preemptible RCU *does not* use context-switch as a quiescent >> state. >> > > > It doesn't? >> > > >> > > I thought that's what preemptible rcu is about. You can get preempted >> but >> > > you shouldn't block in a read-section. Is that not true? >> >> > Almost. All context switches in an RCU-preempt read-side critical section >> > must be subject to priority boosting. Preemption is one example, because >> > boosting the priority of the preempted task will make it runnable. >> > The priority-inheritance -rt "spinlock" is another example, because >> > boosting the priority of the task holding the lock will eventually make >> > runnable the task acquiring the lock within the RCU-preempt read-side >> > critical section. >> >> Yes I understand priority boosting is needed with preemptible RCU so that >> read-sections are making forward progress. I meant (and correct me if I'm >> wrong) that, as long as a task doesn't sleep in a preemptible RCU >> read-section (rcu-preempt flavor), then bad things wont happen and RCU will >> work correctly. > > The exception is -rt "spinlock" acquisition. If the "spinlock" is held, > the task acquiring it will block, which is legal within an RCU-preempt > read-side critical section. > > This exception is why I define bad things in terms of lack of > susceptibility to priority boosting instead of sleeping.
Oh, that's a tricky situation. Thanks for letting me know. I guess my view was too idealistic. Makes sense now. >> > > I was asking why rcu-bh is needed in the kernel, like why can't we just >> use >> > > rcu-preempt. As per above link, the motivation of rcu-bh was to prevent >> > > denial of service during heavy softirq load. I was trying to understand >> > > that usecase. In my mind, such denial of service / out of memory is then >> > > even possible with preemptible rcu which is used in many places in the >> > > kernel, then why not just use rcu-bh for everything? I was just studying >> > > this RCU flavor (and all other RCU flavors) and so this question popped >> up. >> >> > Because RCU-bh is not preemptible. >> >> > And the non-DoS nature of RCU-bh is one challenge in my current quest to >> > fold all three flavors (RCU-bh, RCU-preempt, and RCU-sched) into one >> > flavor to rule them all. ;-) >> >> But what prevents DoS'ing of RCU-preempt? That means all RCU-preempt uses >> in the kernel are susceptible to DoS'ing as well? > > Right now, not much. So this is one of the problems I must solve. Oh, ok. >> Isn't the issue the heavy softirq processing itself which can also lead to >> other issues such as scheduling issues (other than the OOM) so probably >> that should be fixed instead of RCU? > > In theory, yes. In practice, the way that the kernel hangs leads them > to yell at me about RCU instead of yelling at whoever is behind the > root cause. So it behooves me to make RCU able to deal with whatever > shows up, at least where reasonably feasible. Otherwise, I am signed up > to fix random DoS-related bugs though more that 20 million lines of code, > which would be a nobel quest, but not one that I am currently prepared > to sign up for. ;-) Yes, I understand. :-) thanks, - Joel