[linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Ingo Molnar]

* Scott Wood <scott at timesys.com> wrote:

> Likewise, interrupts are "designed" to be unpreemptible, but it is
> possible to run them in their own threads so as to further reduce
> sources of latency (at a throughput cost, of course).  This allows
> long-held spinlocks that an interrupt handler needs to acquire to be
> replaced with mutexes that don't inhibit preemption.
> 
> Of course, a better fix is to keep the interrupt handlers and critical
> sections short, but threading them can be very effective for producing
> low latencies in the short term (we were able to achieve worst
> measured case latencies of well under 100us on ordinary PC hardware
> under 2.4.x using this approach).

do you have a 2.6 patch for hardirq redirection too? I always thought
this to be the best approach to achive hard-RT class latency guarantees
under Linux (but never coded it up). The problem with RTLinux is that it
introduces a separate OS (with separate APIs). It is (much) further
ahead of Linux in terms of latencies, algorithms and guarantees but is
still a separate OS. I believe there is a natural synergy between low
latencies needed for good desktop and multiuser performance and
soft-RT/hard-RT needs, which we should use - RTLinux doesnt generate
this synergy.

if both hardirqs and softirqs are redirectable to process contexts then
the only unpredictable latency would be the very short IRQ entry stub of
a new hardirq costing ~5 usecs - which latency is limited in effect
unless the CPU is hopelessly bombarded with interrupts.

to solve the spinlock problem of hardirqs i'd propose a dual type
spinlock that is a spinlock if hardirqs are immediate (synchronous) and
it would be a mutex if hardirqs are redirected (asynchronous). Then some
simple driver could be converted to this RT-aware spinlock and we'd see
how well it works. Have you done experiments in this direction? I
believe this all could be merged upstream, given sufficient cleanliness.

	Ingo