Re: Real-Time Preemption and RCU

[Esben Nielsen]

On Tue, 22 Mar 2005, Ingo Molnar wrote:

> 
> * Esben Nielsen <simlo@xxxxxxxxxx> wrote:
> 
> > > > +static inline void rcu_read_lock(void)
> > > > +{	
> > > > +	preempt_disable(); 
> > > > +	__get_cpu_var(rcu_data).active_readers++;
> > > > +	preempt_enable();
> > > > +}
> > > 
> > > this is buggy. Nothing guarantees that we'll do the rcu_read_unlock() on
> > > the same CPU, and hence ->active_readers can get out of sync.
> > > 
> > 
> > Ok, this have to be handled in the mitigration code somehow. I have already 
> > added an 
> >   current->rcu_read_depth++
> > so it ought to be painless. A simple solution would be not to
> > mititagrate threads with rcu_read_depth!=0.
> 
> could you elaborate?
> 
Put an rcu_read_depth on each task. In rcu_read_lock() make a 
 current->rcu_read_depth++;
and visa versa in rcu_read_unlock(). In can_migrate_task() add
   if(p->rcu_read_depth)
         return 0;
That might do the trick.
 

> In any case, see the new PREEMPT_RCU code in the -40-07 patch (and
> upwards). I've also attached a separate patch, it should apply cleanly
> to 2.6.12-rc1.
> 

I barely have time to download at the patches - let alone applying them!

Anyway: I find one thing I don't like: using atomic_inc()/dec() in
rcu_read_lock()/unlock() to touch rcu_data which might be on another
CPU. Then rcu_data is not really per-CPU data anymore and it also hurts
performance of RCU readers.
I think it will be cheaper to use the above rcu_read_depth and then either
not migrate tasks at all or make the migrate code take care of migrating
the rcu_read_depth count to the new CPU - one would have to take care to
increment it in the rcu_data of the new CPU on the new CPU (it isn't
atomic) and then decrement it in the rcu_data of the old CPU on the old
CPU - in that order.


> 	Ingo
> 


Esben

-
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/