Threaded interrupts and preemption

[Chase Douglas]

On Mon, Apr 12, 2010 at 10:56 PM, Alessio Igor Bogani
<abogani at ubuntu.com> wrote:
> Hi,
>
> 2010/4/13 Chase Douglas <chase.douglas at canonical.com>:
> [...]
>> specifically set it up otherwise. I think it would be fun to have an
>> RT completely preemptible kernel just so we can try it out and have a
>> comparison. We would gain an insight as to whether a responsiveness
>> issue is scheduler algorithm based or latency based.
>
> sudo apt-get install linux-rt

As far as I know, our -rt isn't what everyone else means when they say
RT. Our rt flavor just has full preemption and a higher tick rate.
That's nothing compared to what is in the RT patch set maintained by
tglx at http://www.kernel.org/pub/linux/kernel/projects/rt/. The
biggest changes that I'm aware of is the default threaded irq handlers
and complete preemption in his patch set. Ubuntu kernels since at
least Karmic have had threaded irq handlers, but the driver has to be
reworked for it.

I'll probably look into branching the Lucid kernel and applying the
.33 RT patch set, backporting where necessary. Again, I think this is
more to help us gauge how a desktop system behaves on an RT
low-latency kernel than to be a test for wider use at this point.
According to the commit message for the threaded irq handlers in
mainline the RT approach of defaulting to threaded handlers is a blunt
tool and some softirq/tasklet interactions may cause issues. However,
if we find that the RT patch set works wonders we can potentially use
some latency benchmarking tools to determine what is causing extra
latency. Maybe we can find the top latency causing irqs and port them
to threaded handlers. It doesn't seem too difficult to do since many
drivers already just work with the RT patch set.

-- Chase