Message-ID: <Pine.LNX.4.64.0607281154410.10047@localhost.localdomain>
Date:	Fri, 28 Jul 2006 12:14:18 +0100 (BST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	"Paul E. McKenney" <paulmck@...ibm.com>
cc:	Bill Huey <billh@...ppy.monkey.org>,
	Esben Nielsen <nielsen.esben@...glemail.com>,
	linux-kernel@...r.kernel.org, compudj@...stal.dyndns.org,
	rostedt@...dmis.org, tglx@...utronix.de, mingo@...e.hu,
	dipankar@...ibm.com, rusty@....ibm.com
Subject: Re: [RFC, PATCH -rt] NMI-safe mb- and atomic-free RT RCU



On Thu, 27 Jul 2006, Paul E. McKenney wrote:

> On Thu, Jul 27, 2006 at 05:48:57PM -0700, Bill Huey wrote:
>> 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.
>
> 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).
>
> 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?
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.

Esben

>
>> 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).
>
> Yep -- create something sort of like brlock, permitting limited read-side
> parallelism, and also permitting the current exclusive-lock priority
> inheritance to operate naturally.
>
> Easy enough to do with per-CPU variables if warranted.  Although the
> write-side lock-acquisition latency can get a bit ugly, since you have
> to acquire N locks.
>
> I expect that we all (myself included) have a bit of learning left to
> work out the optimal locking strategy so as to provide both realtime
> latency and performance/scalability.  ;-)
>
> 							Thanx, Paul
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists