Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Ingo Molnar (mingo_AT_elte.hu)
Date: Thu Jul 22 2004 - 00:45:34 EEST
* 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
This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:19:51 EEST