22 Jul
2004
22 Jul
'04
12:43 a.m.
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