Re: Real-Time Preemption and RCU

[Paul E. McKenney]

On Fri, Mar 18, 2005 at 05:17:29AM -0800, Bill Huey wrote:
> On Fri, Mar 18, 2005 at 04:56:41AM -0800, Bill Huey wrote:
> > On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
> > > 5. Scalability -and- Realtime Response.
> > ...
> > 
> > > 	void
> > > 	rcu_read_lock(void)
> > > 	{
> > > 		preempt_disable();
> > > 		if (current->rcu_read_lock_nesting++ == 0) {
> > > 			current->rcu_read_lock_ptr =
> > > 				&__get_cpu_var(rcu_data).lock;
> > > 			read_lock(current->rcu_read_lock_ptr);
> > > 		}
> > > 		preempt_enable();
> > > 	}
> > 
> > Ok, here's a rather unsure question...
> > 
> > Uh, is that a sleep violation if that is exclusively held since it
> > can block within an atomic critical section (deadlock) ?
> 
> I'd like to note another problem. Mingo's current implementation of rt_mutex
> (super mutex for all blocking synchronization) is still missing reader counts
> and something like that would have to be implemented if you want to do priority
> inheritance over blocks.
> 
> This is going to throw a wrench into your implementation if you assume that.

If we need to do priority inheritance across the memory allocator, so
that high-priority tasks blocked waiting for memory pass their priority
on to RCU readers, agreed.  But I don't see any sign that real-time
preempt does this.

In absence of this, as Ingo noted, the fact that readers don't block
each other should make things be safe.  I think...

						Thanx, Paul
-
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/