Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU

[hui]

On Thu, Jul 27, 2006 at 05:02:31PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 27, 2006 at 12:53:56PM -0700, Bill Huey wrote:
> > On Thu, Jul 27, 2006 at 08:46:37AM -0700, Paul E. McKenney wrote:
> > > A possible elaboration would be to keep a linked list of tasks preempted
> > > in their RCU read-side critical sections so that they can be further
> > > boosted to the highest possible priority (numerical value of zero,
> > > not sure what the proper symbol is) if the grace period takes too many
> > > jiffies to complete.  Another piece is priority boosting when blocking
> > > on a mutex from within an RCU read-side critical section.
> > 
> > I'm not sure how folks feel about putting something like that in the
> > scheduler path since it's such a specialized cases. Some of the scheduler
> > folks might come out against this.
> 
> They might well.  And the resulting discussion might reveal a better
> way.  Or it might well turn out that the simple approach of boosting
> to an intermediate level without the list will suffice.

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.

This was close to the idea I had for extending read/write locks to be more
parallel friendly for live CPUs, per CPU owner bins on individual cache lines
(I'll clarify if somebody asks), but the use of read/write locks is seldom
and in non-critical places, so just moving the code fully to RCU would be a
better solution. The biggest problem is to scan or denote to some central
structure (task struct, lock struct) when you were either in or out of the
reader section without costly atomic operations. That's a really huge cost
as you know already (OLS slides).

bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/