On Wed, Sep 26, 2007 at 10:28:33AM +0200, Peter Zijlstra wrote:
> On Tue, 25 Sep 2007 18:11:39 -0700 "Paul E. McKenney"
> <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Sep 26, 2007 at 01:24:47AM +0200, Peter Zijlstra wrote:
> > > On Tue, 25 Sep 2007 16:02:45 -0400 (EDT) Steven Rostedt
> > > <[EMAIL PROTECTED]> wrote:
> > > 
> > > > > This would of course require that synchronize_all_irqs() be in the
> > > > > RCU code rather than the irq code so that it could access the static
> > > > > wakeme_after_rcu() definition and the rcu_synchronize structure.
> > > > >
> > > > > Thoughts?
> > > > 
> > > > I do like this better. Anyone else care to comment?
> > > 
> > > I'm still wondering why the IRQ users cannot user proper RCU as it
> > > stands:
> > 
> > Well, that was my initial proposal.  ;-)
> 
> handler: 
> > >   rcu_read_lock();
> > >   foo = rcu_dereference(bar);
> > >   if (foo)
> > >     foo();
> > >   rcu_read_unlock();
> >
> 
> control routine (!handler)
> > > vs
> > > 
> > >   rcu_assign(foo, NULL);
> > >   synchronize_rcu();

Ah, OK -- yes, that was what I originally proposed -- that individual
handlers using RCU place the rcu_read_lock() and rcu_read_unlock() as
needed.

> > > The implicit rcu_read_lock() as placed in handle_IRQ_event() seems
> > > misplaced.
> > 
> > OK -- where would you put them instead?  I have them covering the
> > call to the handler, so what am I missing here?
> 
> in do_hardirq() (-rt) that is specific to threaded interrupts.

My concern there is that some of the functions called from do_hardirq()
can loop processing multiple interrupts.  An interrupt storm, otherwise
harmless in -rt, could cause a very long RCU read-side critical section
if it happened within thread_edge_irq().

> That said, I'm wondering if we need this whole extra sync_all_irqs()
> thing. I'm just not getting why IRQ handlers should be an implicit RCU
> safe context.

Because they are in non-rt -- synchronize_sched() is guaranteed to
wait for all interrupt handlers.  In contrast, in -rt, synchronize_sched()
only waits for hardirq.  So Dmitry Torokhov asked for a primitive
that would wait for all irq handlers, whether threaded or not.

But given that he has not responded to this thread, perhaps he
found that synchronize_irq() worked for him.

                                                Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to