It's been pointed out to me that this discussion was taking place, and
I suppose I should say something about it, given that people are
talking about messing with code that I'm responsible for, and now that
I've effectively been slagged regarding `low level performance'.

It's true that FreeBSD has somewhat lower quoted `interrupt latency'
for serial interrupts.  Unfortunately, the way they do this is with a
specific one-off hack just for that case.  It's totally
non-extensible.  I specifically reworked our `com' driver without
using a `fast interrupt' to demonstrate that it's *not* needed to get
good serial performance.  (In addition, in my testing, we actually get
better low-level serial performance now -- because the rest of the
code path is well-tuned in a way that sio simply is not.  Although the
line discipline interface does need some optimization.)

All that aside, because interrupt deferrals are still processed when
in the serial interrupt handler, and because the soft interrupt
routine may block the hardware interrupt handler for brief periods,
there is always the possibility of additional jitter.  Reducing the
jitter to an absolute minimum would require severely hacking the
driver in ways that I am simply not willing to do (or have done) for
what hardly even qualifies as a corner case.  This is simply too large
a set of special-case behaviour, and too much of a maintenance hassle,
for a generic driver that so many people use.

Worse than that, however, is that reducing jitter is actually
fundamentally incompatible with one of the things you wanted to do --
namely, call the line discipline input routine directly from the
interrupt handler.  The line discipline may call the scheduler; thus,
if the interrupt handler called the line discipline directly, it would
have to be blocked by at least the clock interrupt, and jitter would
increase rather substantially.  (Not that I see any actual reason to
call the line discipline directly anyway, but I digress.)

If you're going to do this with a serial line, I suggest that you just
write a completely separate special-case driver that does what you
need.