-- On Thu, 9 Aug 2007, Robert de Vries wrote: > On 8/8/07, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > 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? You would think. But that's something that the Linux kernel should expect. This can happen on a system where it's not no RT, but more soft RT (God I hate that term). Meaning, the "optimization" of running softirqs as threads can actually cause longer latencies to the interrupt. Since any time an RT task preempts the IRQ while running bounded to a CPU, it will be like masking that interrupt for the full time the RT task is running. > 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. This can't always be done. Say you only have two CPUS, and there's two RT tasks that run at high priorities, on each. But it could be period that the two don't always run at the same time. You don't want to stop an IRQ when it gets preempted by one of the RT tasks. So my answer to you is, no, it is not just a misconfiguration of the system. By making an optimization, we just added a latency that would not be there without that optimization. And it wouldn't be something that one would expect. -- 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
