Thread (23 messages) 23 messages, 4 authors, 2007-09-27

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help