Another example is in the network drivers. The 8390 core for one example
carefully disables an IRQ on the card so that it can avoid spinlocking on
uniprocessor boxes.
So with pre-empt this happens
driver magic
disable_irq(dev->irq)
PRE-EMPT:
[large periods of time running other code]
PRE-EMPT:
We get back and we've missed 300 packets, the serial port sharing
the IRQ has dropped our internet connection completely.
["Don't do that then" isnt a valid answer here. If I did hold a lock
it would be for several milliseconds at a time anyway and would reliably
trash performance this time]
There are numerous other examples in the kernel tree where the current code
knows that there is a small bounded time between two actions in kernel space
that do not have a sleep. They are not spin locked, and putting spin locks
everywhere will just trash performance. They are pure hardware interactions
so you can't automatically detect them.
That is why the pre-empt code is a much much bigger problem and task than the
low latency code.
Alan
-
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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:39 EST