--
On Thu, 9 Aug 2007, Robert de Vries wrote:
> On 8/8/07, Steven Rostedt <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]