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

[Scott Wood <scott@timesys.com>]

On Wed, Jul 21, 2004 at 11:45:34PM +0200, Ingo Molnar wrote:
> do you have a 2.6 patch for hardirq redirection too? 

Yes, and I'll try to get it cleaned up and posted soon.  It depends
on threaded softirqs, though (so I'll have to do something with the
local_bh_disable; probably put it back to the way it was, at least
for now).

> 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). 

If you really want hard-RT-type guarantees, though, you'd need to go
with a scheme whereby interrupts/preemption are disabled only where
the code has specifically been "approved" as not capable of causing
excessive latency (which IRQ threads are a step towards, and which is
what we did in 2.4), as opposed to the current scheme of benchmarking
latencies and fixing those places which actually show up as being
problematic.  There's always the possibility that a different usage
case will show up later, causing the latency in some piece of code to
go way up.

> 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.

Those aren't the only sources; you also have preempt_disable() and
such (as well as hardware weirdness, though there's not much we can
do about that).

> 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? 

This sort of substitution is what we did in 2.4, though we made this
type the default and gave the real spinlocks a new name to be used in
those few places where it was really needed.  Of course, this
resulted in a lot of places using a mutex where a spinlock would have
been fine.

-Scott