DragonFly kernel List (threaded) for 2006-12
DragonFly BSD
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?


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 10 Dec 2006 21:48:24 -0800 (PST)

    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]