Re: Time sharing for interrupt threads

--------
John Baldwin writes:

> In the old interrupt masking implementation in FreeBSD 4.x and before,
> pending interrupts (both hardware and software) were tracked in a bitmask
> [...]
> At least some versions of Solaris (the one my Solaris Internals book 
> describes) don't assign differing priorities to ithreads at all [...]

The original priority assignment we inherited in the SPL mechanism
was mandated by ideosyncrasies of specific hardware-interfaces on
the PDP/11, specifically DMA vs non-DMA transfers.

Back then, serial interfaces, both asynchronous and synchronous,
had neither FIFO buffers nor DMA, so their interrupts had to be
served within one character interval, or they would drop data.
A very real issue on a 1 MIPS machine with 50 serial ports.

Already back in the 1980'ies, "big-iron" UNIX vendors had mitigated
this with "intelligent serial adapters" or all sorts.

When we came on the scene with our PC hardware, and it's two or
more serial ports at 115200, the problem was back, and even the
traditional SPL ordering was barely enough, so we got "fast interrupts"
to implent a software FIFO (Thanks @bde!).

In OS-theory, interrupt priorites should depend only on the need to
serve the hardware "in a timely manner".

In real life that may not have anything to do with the hardware,
for instance an emergency stop button.

The wisdom of prioritizing "NET" over "DISK" or vice versa, will
almost by definition depend on the actual application, so my proposal
would be to classify drivers into some broard classes, "NET", "DISK",
"GPIO", "GRAPHICS" etc, each with a sysctl setting the priority.

I would set NET and DISK to the same priority out of the box.

For further granularity of tuning we could also have sysctls per
driver instance or per interrupt.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.