On Wed, Sep 26, 2007 at 01:44:22PM -0400, Steven Rostedt wrote:
> --
> On Wed, 26 Sep 2007, Dmitry Torokhov wrote:
> > > The synchronize_all_irqs() will not return until:
> > >
> > > 1. All pre-existing hardirqs have completed.
> > >
> > > 2. All pre-existing threaded irqs have completed.
> > >
> > > 3. All preempt_disable() regions of code have completed.
> > >
> > > 4. All irq-disable regions of code have completed.
> > >
> > > It will not necessarily wait for all softirqs to complete, but
> > > then again, synchronize_sched() in non-rt might not wait for all
> > > softirqs either, for example, if ksoftirqd is handling softirqs.
> > >
> > > Does that do what you need, or am I missing a case that needs
> > > to be covered?
> >
> > As long as the list includes code guarded by
> > spin_lock_irqsave()/spin_unlock_irqrestore() I am happy. Does this
> > count as an irq-disable region? Peter said earlier that in -rt such
> > code still runs with IRQs enabled...
>
> No it does not guarantee that in -rt. Peter is correct that in the -rt
> patch, spin_lock_irqsave and restore do not touch actual interrupts (when
> PREEMPT_RT is configured). And the above protections that Paul has shown
> also does not guarantee that all spin-locks will be released.
>
> spin_locks in -rt become mutexes, and if some low priority process grabs
> some spin_lock somewhere that no other process cares about, and then this
> process gets preempted by a bunch of RT hogs, that lock could be held for
> an awfully long time.
>
> Paul, has there been any work to guarantee such a thing?
Well, we could make spin_lock_irqsave() invoke rcu_read_lock() and
spin_lock_irqrestore() invoke rcu_read_unlock(), with similar adjustments
to the other primitives in this group. Then RCU priority boosting would
kick in if configured.
Of course, someone who is not quite so closely linked to RCU might be
able to come up with some other solution. ;-)
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
