Subject: interrupt latency - next round
To: None <tech-kern@netbsd.org>
From: Leo Weppelman <leo@wau.mis.ah.nl>
List: tech-kern
Date: 05/17/2000 11:11:12
I _think_ I found the root of the problem. It seems to be caused by the
latency between the actual interrupt and the time of the callback. If
I just eliminate the callback and let the interrupt happen at the wrong
time (while it should be blocked), I get an occaisional pool-panic, but
no overruns.

[ description of Atari interrupt handling ]
On the atari, (almost) all interrupts arrive at ipl6 (ipl7 == highest). The
interrupt sources are managed by one or two 68901 MFP's and delivered to the
CPU. In practice, this means that the kernel has to do some interrupt
rescheduling, since you don;t want ISA and clock interrupts at the same ipl.
I use the software-interrupt mechanism to do this. And this seems to be too
slow sometimes.

So it looks that I have to rewrite this. I was thinking about creating
an interrupt queue per spl-level and modifying splx to check these queues
each time the ipl was lowered. The problem is that there are some places that
the ipl is implicitely changed (cpu_switch is a nice example) and that the
overhead of splx increases.
I also thought about implementing spl/splx by playing with the mfp interrupt
masks. This method has also problems with implicit spl changes btw.

Does anybody know of prior art in this area? Or maybe has a better idea of
how to handle this...

Leo.