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