lkml.org 
[lkml]   [2006]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-07-28 17:29    [W:0.040 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site