Polling for devices other than NICs [patch]

[Nate Nielsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ed Maste wrote:
> In addition, the current polling algorithm breaks down when you get to
> very high CPU utilization by the stack (e.g. if acting as a high
> bandwidth router).  This happens because it adds one count per tick
> if the polling did not run longer than one hardclock interval, but
> brings it down to 7/8ths if it did.
> 
> This ends up producing a sawtooth effect in the amount of work done by
> the polling handlers.  Andre Oppermann is performing some high-perf
> stack testing, and he ran into this effect; in polling mode the maximum
> packet rate was achieved while there was still idle CPU time.

Interesting. My (simple) work on this has been on low powered CPU
machines (such as the Soekris single board systems):

http://memberwebs.com/nielsen/freebsd/slow-cpu-routers.html

> I have a proof of concept patch that modifies the polling feedback
> algorithm to measure the amount of time spent in the polling handlers,
> and then attempt to schedule an appropriate amount of work to fill out
> the time slot.  Andre is going to be testing it out shortly.
> 
> Don't get me wrong, I think your patch is a step in the right direction,
> but we do have more work to do in order to completely generalize the
> polling code.

Agreed. And sometime in the future, we should probably work towards
implementing auto-switching between polling and interrupts:

http://www.stanford.edu/class/cs240/readings/mogul.pdf

Cheers,
Nate
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDwwfte/sRCNknZa8RAnMAAJ0de3eQELrbEgp5NF56wFtR2poYBACbBetq
p/ZLh5bY6dbdPiIkIJMsCEM=
=RADi
-----END PGP SIGNATURE-----