DragonFly kernel List (threaded) for 2006-12
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
What do people think about adaptive polling?
This isn't something I'm working on, but I'd like people's opinions
on the idea.
Our biggest problem with new hardware is with interrupt routing.
While I do want DragonFly to be able to route interrupts properly,
I think we need something in the OS that deals with interrupt routing
failures.
The idea is to be able to do an end-run around systems with broken
interrupt routing by instituting adaptive polling. Basically all
devices that can produce events are polled at some reasonable minimum
rate, say 50hz. When polled, the device returns an indication as to
whether it processed any new events or not. A TRUE indication increases
the poll rate for that device, up to some reasonable maximum, and a
FALSE indication decreases the poll rate, down to some reasonable
minimum.
We would then use a heuristic to determine if interrupts are broken
on a device by device basis. Basically we would keep track of whether
an event was processed via the poll or whether it was processed via the
interrupt. Over a period of time we can determine which devices have
working interrupts and which do not.
The ones that are determined to not have working interrupts would be
polled more often and the ones that are determined to have working
interrupts would be polled less often (just enough to keep the heuristic
operational).
I think it is also possible to create a heuristic that detects misrouted
interrupts... a device that the system thinks is interrupting on one
IRQ but which is actually interrupting on another. This would work by
taking the first heuristic above and, when it is determined that an
interrupt is not working, have a DEVOPS command that turns off the
interrupt entirely for a short period of time and then have a second
heuristic which keeps track of spurious interrupts (interrupts for which
no event was processed) and compares spurious interrupts with the device
interrupt on and with it off. Again, over a period of time, it should
be possible to determine which devices have misrouted interrupts.
Despite the complexity of what I am describing, I think the actual
algorithm is quite easy in both concept and implementation.
In particular, we can implement the poll via the standard NEWBUS
interrupt routing calls and just have a flag indicate when a device
*cannot* be polled (i.e. the IDE, PS/2 keyboard, and timer devices).
Devices would only have to be modified to have the interrupt routine
return a TRUE or FALSE instead of void, and could be optionally
retro-fitted with the new NEWBUS command that enables or disables the
interrupt entirely for the second heuristic.
-Matt
Matthew Dillon
<dillon@backplane.com>
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]