I stipulate all you say, with the sole exception that I believe that widening
the character processing path is only one part of the problem - the other is
those spl'd sections of code. (just as an aside, if we're going to change the
tty code interfaces, we should look at V8 streams or the mythical bstreams
(not to be confused with the System V "sewers" network API) as one way to go
in doing a new interface). The Sun3 and Mac68k NetBSD ports already have PDMA,
but they still suffer from the overflows from time to time and expanding the
PDMA buffer won't help - we're not getting to the hardware fifo fast enough.

Expanding a bit more on what my friend had to say, the problem tended to be
bursts of characters, which overflow the fifo (silo, whatever) because
interrupt response of the OS is delayed too long. Granted, his case was
pathological - a one byte serial port fifo in some models of the Amiga, which
made interrupt processing latency absolutely critical: it had to be less than
two character times at the maximum speed of the port.

I only mentioned the clock interrupt handler because that pulls the PC out of
the stack in all NetBSD ports, in order to do the compare against "Idle" -
it's an example of how to grab the previous PC from an interrupt handler.

I had assumed that the "spl" stuff was inlined everywhere so you'd only have
to look one level deep in the interrupt stack. Oh, well - so this is a little
trickier than I thought. We still need to have some measure of where the system
is spending its time when these events occurr...

There will be cases where the hardware is just plain broken in its interrupt
heirarchy, and we're stuck with it; the i386 hack you mention (turning
interrupts into "events" of a sort) sounds like one way around that problem.
I bet those interrupt handlers are really small, too. Doing things this way,
we could even get really kinky and reorder the interrupt processing priorities
on the fly, as needs dictate.

Coincidentally, cleaning up the interrupt latency issue will also make our
system clocks more accurate, disks go faster, it's less fattening, tastes great...

	Erik E. Fair    fair@clock.org