Messages in this thread | | | Date | Fri, 28 Jul 2006 08:25:41 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU |
| |
On Fri, Jul 28, 2006 at 12:14:18PM +0100, Esben Nielsen wrote: > On Thu, 27 Jul 2006, Paul E. McKenney wrote: > >On Thu, Jul 27, 2006 at 05:48:57PM -0700, Bill Huey wrote: > >>Another thing. What you mention above is really just having a set of > >>owners > >>for the read side and not really a preemption list tracking thing with RCU > >>and special scheduler path. The more RCU does this kind of thing the more > >>it's just like a traditional read/write lock but with more parallelism > >>since > >>it's holding on to read side owners on a per CPU basis. > > > >There are certainly some similarities between a priority-boosted RCU > >read-side critical section and a priority-boosted read-side rwlock. > >In theory, the crucial difference is that as long as one has sufficient > >memory, one can delay priority-boosting the RCU read-side critical > >sections without hurting update-side latency (aside from the grace period > >delays, of course).
Here is a better list of the similarities and differences between rwlock and RCU in -rt:
Attribute rwlock RCU
Readers block updates Y N
Readers block freeing Y Y (synchronize_rcu())
Updates block readers Y N
Deterministic readers N Y
Readers block readers Y (-rt!) N
Readers preemptible Y Y
Readers can block on locks Y Y
Readers can block arbitrarily Y N (SRCU for this)
So in rwlock, priority boosting of readers is required to allow updates to happen -at- -all-, while in RCU, priority boosting is required to get deferred free (call_rcu(), synchronize_rcu()) unstuck.
> >So I will no doubt be regretting my long-standing advice to use > >synchronize_rcu() over call_rcu(). Sooner or later someone will care > >deeply about the grace-period latency. In fact, I already got some > >questions about that at this past OLS. ;-) > > Yick!! Do people really expect these things to finish in a predictable > amount of time?
Yeah, this is -almost- as unreasonable as expecting preemptible RCU read-side critical sections!!! ;-) ;-) ;-)
> This reminds me of C++ hackers starting to code Java. They want to use the > finalizer to close files etc. just as they use the destructor in C++, but > can't understand that they have to wait until the garbage collector has > run. > RCU is a primitive kind of garbage collector. You should never depend on > how long it is about doing it's work, just that it will get done at some > point.
Seriously, it probably is not all that hard to get an upper bound on synchronize_rcu() latency, as long as one is willing to put up with the upper bound being a handful of jiffies (as opposed to being down in the microsecond range. In addition, this upper bound would be a function of the number of tasks, and would also require boosting RCU read-side priority to maximum.
That said, a (say) ten-jiffy upper bound on synchronize_rcu() would probably not be what they were looking for. ;-)
Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |