Re: [PATCH RFC -rt] updated synchronize_all_irqs implementation
From: Steven Rostedt <rostedt@goodmis.org>
Date: 2007-09-26 17:45:28
-- On Wed, 26 Sep 2007, Dmitry Torokhov wrote:
quoted
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