Re: linux interrupt handling problem

yodaiken@chelm.cs.nmt.edu
Thu, 11 Nov 1999 13:44:28 -0700


On Thu, Nov 11, 1999 at 10:27:16PM +0300, kuznet@ms2.inr.ac.ru wrote:
> Hello!
>
> Actually, Linux is much better proof of the concept than all the papers,
> is not it?

The argument is made that Linux could be improved by doing X. Not only do
we see Linux do better than another system using X, but we also can see a
simulation exercise that shows, X is worse in principle.

>
> > hands-down. They did note that spl made sense on older machines where
> > interrupt routines were, relatively, much longer due to the slower clock
> > speeds, but concluded that it didn't make sense on modern, fast CPUs.
>
> Provided these modern fast CPUs serve old slow peripheral devices
> or devices, which are insensitive to latency. Do we really leave dumb,
> but high speed, serial devices to RTlinux or to that poor netbsd? 8)

Are there really many such devices in use for non RT sorts of things?
What use do they have?

> Note also, when irq disabling is combined with spinlocks,
> latency bounds are difficult to control, if it is possible at all.
> Al least, multiply by maximal depth of nested locks and by number of cpus...

Isn't problem here unfocused interrupts. If you are having lock contention,
speeding up locks is perhaps not the correct first approach.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/