--
> > > +void synchronize_all_irqs(void)
> > > +{
> > > + if (hardirq_preemption)
> > > + synchronize_rcu(); /* wait for threaded irq handlers. */
> > > + synchronize_sched(); /* wait for hardware irq handlers. */
> >
> > I don't undrestand the synchronize_sched part above. How does that wait
> > for all hardware irq handlers? Wouldn't the synchronize_rcu be sufficient?
>
> In practice, given the current implementations of RCU, agreed. However,
> an RCU implementation would be within its rights to return immediately
> from synchronize_rcu() if it could somehow deduce that there happened
> to be no RCU read-side critical sections in progress at that moment.
> This could leave hardware interrupt handlers still running on other CPUs.
>
> In fact, the QRCU implementation (http://lkml.org/lkml/2007/2/25/18)
> is an example RCU implementation that is capable of returning from
> synchronize_qrcu() extremely quickly if there are no QRCU readers (a
> few tens of nanoseconds on a recent x86-64 box). Hardware irq handlers
> could easily be running for much longer (like if they take even a single
> cache miss).
>
> That said, having serialized delay that is almost never necessary is
> not such a good thing. One thing I could do would be to open-code
> synchronize_rcu() in synchronize_all_irqs(), so that the delays for RCU
> and for synchronize_sched() happened in parallel. Something like:
>
> void synchronize_all_irqs(void)
> {
> struct rcu_synchronize rcu;
>
> if (hardirq_preemption) {
> init_completion(&rcu.completion);
> /* Will wake me after RCU finished */
> call_rcu(&rcu.head, wakeme_after_rcu);
> }
>
> /* wait for hardware irq handlers. */
>
> synchronize_sched();
>
> /* wait for threaded irq handlers. */
>
> if (hardirq_preemption)
> wait_for_completion(&rcu.completion);
>
> }
>
> 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?
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
