Re: Real-Time Preemption and RCU

["Paul E. McKenney" <paulmck@us.ibm.com>]

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