Messages in this thread | | | Date | Wed, 21 Jul 2004 23:45:34 +0200 | From | Ingo Molnar <> | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* Scott Wood <scott@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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |