I don't actually like this patch very much - I think it goes about what it
is doing the wrong way.
The problem is that we want to make serial interrupts fast (thus no bottom
half handling) but at the same time we _do_ want to do bottom half and all
the rest (process switching etc) occasionally when a new packet has come
in.
This patch looks like it is going about this by having the actual
interrupt handler do all of the handling occasionally. I dislike this idea
immensely - that is not how things are supposed to work, and it special
cases something that is really a generic issue. It also looks like a
horrible thing from an SMP standpoint, actually (doing a global cli/sti in
the serial line interrupt handler counts as a really bad thing (tm)).
I've seen other patches that do this much more cleanly: by having the
interrupt handler return a return value indicating whether it wants to be
fast or not. This has the added advantage that it also solves the current
problem with shared PCI interrupts where one handler wants to be fast, and
the other one wants to be slow.
In short, I'd much rather see a patch that
(a) gets rid of the "fast" vs "slow" interrupts. They used to make sense,
but they don't much do that any more. They only result in problems.
(b) make the interrupt handler routine return a flag whether we should do
bottom half processing after this interrupt. This flag is "or"ed
together for all shared interrupts, and upon exit from the interrupt
we then decide whether we should do the bottom half or not.
(c) make "ret_from_interrupt" be different from "ret_from_sys_call",
because we no longer want to return to ret_from_sys_call() because we
already did bottom half handling.
And after the above patch, speeding up slip/ppp latency is just a matter
of returning 1 in the serial interrupt handler when we have a full packet.
Linus