On Thursday 09 August 2007 02:49:27 Robert de Vries wrote: > On 8/8/07, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > 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. > > Wouldn't a developer of a real-time system configure the system so > that interrupts do not interfere with the real-time tasks running on a > specific CPU? > In other words, is this problem not simply a misconfiguration of the > system? I personally redirect all interrupts away from the CPU's where my > real-time tasks run and only allow the interrupts that I want to > handle in my application on the CPU's where I handle them so as to > minimize latency. I think the goal is to try and have a generally robust default setup - but the interrupt shielding you are suggesting seems like it will become more and more relevant as the number of CPUs increases. -- Darren Hart IBM Linux Technology Center Realtime Linux Team - 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
