On a PC.
I would actually submit that the rest of the argument Linus makes is
correct. The biggest problem we have is the gratuitious use of cli/sti.
On my test Mac68K kernel I've actually got cli() only blocking some
levels of IRQ (M68K does have levels), not by notion of "Priority" although
thats a hardware implementation feature in this case.
With cli "fixed" my serial driver on a 68K mac clocks 38400 baud without
dropping a bit. This is on a 16Mhz 68020 CPU. To do localtalk I have to
hit 90microsecond interrupt latency at all times. The only thing that
stops that is the sledgehammer approach to locking.
The fact I can do this without running RTLinux tells me that we have
things to improve now we have the right underlying locking mechanisms.
For 2.3 we really really need to change the save_flags behaviour to
save not some magic irq bit but a bitmask or cookie.
Almost every cli in the kernel is in fact really
block_interrupt(dev->irq)
something
unblock_interrupt(dev->irq)
Where dev->irq is the device irq.
Its not quite that simple because sometimes devices share locks (which is
generally broken but not always), so it comes down to
request_irq(foo)
attach_spinlock_to_irq(lock1)
attach_spinlock_to_irq(lock2)
so each spinlock locks only the irqs neccessary for its blocks. Right
now a spinlock is almost as bad as a cli/sti.
2.3 stuff alas
> spl-levels is not the answer. net_bh() may be a bad implementation, but I
> think you're dreaming if you think NT and BSD behave better because of
> spl-levels.
Not doing first level packet processing in the interrupt is the cause.
net_bh() is not itself the guilty party. The amount of code executed
between a receive irq and net_bh and the transmit irq is the problem. Since
the bh code is pretty lean the only thing sensible left to do is to short
circuit it completely. There are also irq in bh handling interactions that
make things far worse when going via net_bh than first apparent. Especially
as packet arriving events cause data copies and flush the old packet out of
L1.
0.97 or so did stuff directly off irq handlers.
In the general case packet copy/demux is too expensive to do in the irq
handler itself (networking is generally bursty so you can 'catch up') but
that requires a clean way to do limited irq disable on locks or to use
net_bh.
For 2.2 net_bh is the only sane option.
The real question is how do we sort things out for 2.2. I would submit
the answer to that is to leave dev->tbusy as it is. dev->interrupt was
right when it was created but its semantics no longer quite do what they
want. If we fix anything other than dev->interrupt we should fix the
error timeout handling. That is in truth a bigger weakness than
tbusy.
Alan
-
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/