Messages in this thread | | | Date | Fri, 18 Mar 2005 10:28:16 +0100 | From | Ingo Molnar <> | Subject | Re: Real-Time Preemption and RCU |
| |
* Ingo Molnar <mingo@elte.hu> wrote:
> > * Paul E. McKenney <paulmck@us.ibm.com> wrote: > > > I have tested this approach, but in user-level scaffolding. All of > > these implementations should therefore be regarded with great > > suspicion: untested, probably don't even compile. Besides which, I > > certainly can't claim to fully understand the real-time preempt patch, > > so I am bound to have gotten something wrong somewhere. [...] > > you dont even have to consider the -RT patchset: if the scheme allows > forced preemption of read-side RCU sections on current upstream > CONFIG_PREEMPT, then it's perfect for PREEMPT_RT too.
there's one detail on PREEMPT_RT though (which i think you noticed too).
Priority inheritance handling can be done in a pretty straightforward way as long as no true read-side nesting is allowed for rwsems and rwlocks - i.e. there's only one owner of a lock at a time. So PREEMPT_RT restricts rwsem and rwlock concurrency: readers are writers, with the only exception that they are allowed to 'self-nest'. I.e. things like:
read_lock(&rwlock); ... read_lock(&rwlock);
are still legal. (it's also done quite often.)
(it is virtually impossible to implement priority inheritance for true multi-reader locks in any sane way: i've done it initially and it sucks very much. It also fundamentally increases the 'lock-dependent' worst-case latencies - imagine 4 readers having to finish first if a higher-prio writer comes along. It's insane.)
Ingo - 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/
| |