Messages in this thread | | | Date | Fri, 18 Mar 2005 07:33:25 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Real-Time Preemption and RCU |
| |
On Fri, Mar 18, 2005 at 10:53:27AM +0100, Ingo Molnar wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > > > 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'. > > [...] > > this does not affect read-side RCU, because read-side RCU can never > block a higher-prio thread. (as long as callback processing is pushed > into a separate kernel thread.) > > so RCU will be pretty much the only mechanism (besides lock-free code) > that allows reader concurrency on PREEMPT_RT.
This is a relief! I was wondering how on earth I was going to solve the multi-task priority-inheritance problem!
But... How do we handle the following scenario?
0. A bunch of low-priority threads are preempted in the middle of various RCU read-side critical sections.
1. High-priority thread does kmalloc(), but there is no memory, so it blocks.
2. OOM handling notices, and decides to clean up the outstanding RCU callbacks. It therefore invokes _synchronize_kernel() (in implementation #5).
3. The _synchronize_kernel() function tries to acquire all of the read-side locks, which are held by numerous preempted low-priority threads.
4. What now???
Or does the current patch do priority inheritance across the memory allocator? In other words, can we get away with ignoring this one? ;-)
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/
| |