polling's future [was: Re: Dynamic Ticks/HZ]
ticso at cicely7.cicely.de
Sun Nov 11 11:16:25 UTC 2012
On Tue, Nov 06, 2012 at 10:46:28AM +0000, Poul-Henning Kamp wrote:
> In message <5098E8B4.5040309 at freebsd.org>, Andre Oppermann writes:
> >> I think it should go away, and if there still is a relevant
> >> usage segment, be replaced by _real_ "device-polling" which is
> >> not tied to the network stack.
> >Don't we already have the equivalent with a fast interrupt thread
> >that simply acknowledges and disables the interrupt [...]
> The point is that not all hardware have interrupt-pacing, so
> being able to poll at a lower rate in software would save overhead.
> I'm not sure if the hardware where this applies is still relevant,
> it would probably be mostly in the embedded space.
I've used polling on embedded systems to avoid userland starvation and
not to gain bandwidth.
Interrupts have priority over userland processes and with a CPU not capable
to handle say 100MBit/s ethernet interrupt load you can't even login via
With polling such a machine is way more responsive and allow people to find
out that there is a saturated link before pulling the plug.
There are likely other solutions, but it worked well for that puprose.
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the freebsd-current