Threaded interrupts and preemption
Daniel J Blueman
daniel.blueman at gmail.com
Tue Apr 13 10:25:28 UTC 2010
On Tue, Apr 13, 2010 at 11:23 AM, Daniel J Blueman
<daniel.blueman at gmail.com> wrote:
> On Tue, Apr 13, 2010 at 7:11 AM, Chase Douglas
> <chase.douglas at canonical.com> wrote:
>> On Mon, Apr 12, 2010 at 10:56 PM, Alessio Igor Bogani
>> <abogani at ubuntu.com> wrote:
>>> 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.
> I think offering a realtime-enabled kernel does bring some wins to
> Ubuntu, for example Novell's SuSE Linux Enterprise Realtime is the
> only mainstream offering right now (and I believe is only the kernel),
> though it does come with expense to normal throughput.
> On another angle, the faster processors and memory are, the relatively
> longer is spent synchronously waiting for disk, network, timers,
> MMIO/PIO register reads/barriers etc, and there is some benefit in
> using the '-rt' kernel with due to the preemption outside spinlocks
> and atomic regions.
Correction, I mean using the eg linux-image-2.6.32-20-preempt kernels.
Daniel J Blueman
More information about the kernel-team