Subject: Re: device polling system
To: Takahiro Igarashi <email@example.com>
From: mouss <firstname.lastname@example.org>
Date: 06/02/2003 13:54:30
At 01:55 29/05/2003 +0900, Takahiro Igarashi wrote:
>what do you means "on the fly" for? If it is that kernel
>choices ether interrupt-driven or polling on some time, I
>dont know the OSes which do so. If it requires reasonably,
>I must implement it.
>If it is that simply to switch between them, this code is
>partly implemented. I'll change switch from all or nothing
>to nic base choice.
One possibility would be to
1- switch from interrupt to polling if load is higher than some threshold T1
load may be "speed" of interrupts (or "acceleration" so as to be somewhat
2- switch back to interrupt if load is below some threshold T2
(with T2 <=3D T1, possibly different).
This requires keeping traffic infos. more elaborate algos might be better
(but would add complexity?)
See also: 'Can I turn on polling only when overloaded, and use interrupts=20
in: "Device Polling support for FreeBSD"
other pointers that might be interesting:
- "Eliminating Receive Livelock in an Interrupt-driven Kernel":
- "Ethernet Device Polling for OpenBSD"
excerpt: "The current code to switch modes automatically is rather retarded.
It will turn off polling if it doesn't get enough traffic, but the very=20
next packet will turn it back on"
- "Linux* Base Driver for the Intel=AE PRO/100 Family of Adapters"
see: RxCongestionControl and PollingMaxWork entries.