Messages in this thread | | | Date | Fri, 18 May 2018 19:29:18 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Tasks RCU vs Preempt RCU |
| |
On Fri, May 18, 2018 at 11:36:23AM -0700, Joel Fernandes wrote: > Hi, > > I was thinking about tasks-RCU and why its needed. Since preempt-RCU allows > tasks to be preempted in read-sections, can we not just reuse that mechanism > for the trampolines since we track all preempted tasks so we would wait on > all tasks preempted within a trampoline? > > I am trying to understand what will _not_ work if we did that.. I'm guessing > the answer is that that would mean the trampoline has to be wrapped with > rcu_read_{lock,unlock} which may add some overhead, but please let me know > if I'm missing something else.. > > The advantage I guess is possible elimination of an RCU variant, and also > possibly eliminating the tasks RCU thread that monitors.. Anyway I was > thinking more in terms of the effort of reduction of the RCU flavors etc and > reducing complexity ideas.
The problem is that if they are preempted while executing in a trampoline, RCU-preempt doesn't queue them nor does it wait on them.
And the problem with wrapping them with rcu_read_{lock,unlock} is that there would be a point before the trampoline executed rcu_read_lock() but while it was on the trampoline. Nothing good comes from this. ;-)
Thanx, Paul
| |