Re: [PATCH RT] Only run softirqs from the irq thread if the irq affinity is set to 1 CPU

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 2007-08-08 at 14:16 -0700, Darren Hart wrote:

> It seems to me that this patch will reduce the frequency of irqd/softirqd 
> starvation, but the core problem still exists: softirq tasks can't migrate to 
> other CPUs to perform their work if a higher priority task preempts them.  
> I'm wondering if we want to keep special casing things to minimize the 
> problem or not - seems to me the worst case is still the same - and isn't the 
> worst case the only case that matters (for -rt)?
> 

softirq tasks should never migrate to other CPUs. A softirq exists in
every CPU. So if you trigger a softirq on CPU1 it will only run on CPU1.
If a high priority task preempts it, that same softirq can still run on
other CPUS. Only the thread that was preempted wont switch. But that's
the characteristic of softirqs, and that's how people who use them in
development expect them to work.

The problem with the IRQ thread, is that there exists only one. If you
preempt it, it will not run anywhere. Even if we tried to do something
like the softirqs where we put one on every CPU, you still have the IRQ
itself masked, and if the IRQ thread gets preempted, that IRQ wont
happen again on another CPU.

Now, I can see a problem with softirqs still being on one CPU, because
we basically have the same problem if a softirq gets preempted while
holding a mutex.  Other softirqs must wait for the RT task that
preempted a softirq finishes. This could cause problems as well.
Especially if the designer of the RT app doesn't understand this.

/me will make a note of this in his RT chapter on "Building Embedded
Linux Systems".

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/