Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
POLLING(4)		 BSD Kernel Interfaces Manual		    POLLING(4)

     polling --	device polling support

     options DEVICE_POLLING
     options HZ=1000

     "Device polling" (polling for brevity) refers to a	technique to handle
     devices that does not rely	on the latter to generate interrupts when they
     need attention, but rather	lets the CPU poll devices to service their
     needs.  This might	seem inefficient and counterintuitive, but when	done
     properly, polling gives more control to the operating system on when and
     how to handle devices, with a number of advantages	in terms of system re-
     sponsivity	and performance.

     In	particular, polling reduces the	overhead for context switches which is
     incurred when servicing interrupts, and gives more	control	on the sched-
     uling of the CPU between various tasks (user processes, software inter-
     rupts, device handling) which ultimately reduces the chances of livelock
     in	the system.

     In	the normal, interrupt-based mode, devices generate an interrupt	when-
     ever they need attention. This in turn causes a context switch and	the
     execution of a interrupt handler which performs whatever processing is
     needed by the device.  The	duration of the	interrupt handler is poten-
     tially unbounded unless the device	driver has been	programmed with	real-
     time concerns in mind (which is generally not the case for	FreeBSD	driv-
     ers). Furthermore,	under heavy traffic, the system	might be persistently
     processing	interrupts without being able to complete other	work, either
     in	the kernel or in userland.

     Polling disables interrupts by polling devices at appropriate times, i.e.
     on	clock interrupts, system calls and within the idle loop.  This way,
     the context switch	overhead is removed. Furthermore, the operating	system
     can control accurately how	much work to spend in handling device events,
     and thus prevent livelock by reserving some amount	of CPU to other	tasks.

     Polling is	enabled	with a sysctl variable kern.polling.enable whereas the
     percentage	of CPU cycles reserved to userland processes is	controlled by
     the sysctl	variable kern.polling.user_frac	whose range is 0 to 100	(50 is
     the default value).

     When polling is enabled, and provided that	there is work to do, up	to
     user_frac percent of the CPU cycles is reserved to	userland tasks,	the
     remaining fraction	being available	for device processing.

     Enabling polling also changes the way network software interrupts are
     scheduled,	so there is never the risk of livelock because packets are not
     processed to completion.

     There are other variables which control or	monitor	the behaviour of de-
     vices operating in	polling	mode, but they are unlikely to require modifi-
     cations, and are documented in the	source file src/sys/kern/kern_poll.c

     Polling requires explicit modifications to	the device drivers.  As	of
     this writing, the dc, fxp,	rl and sis devices are supported, with other
     in	the works.  The	modifications are rather straightforward, consisting
     in	the extraction of the inner part of the	interrupt service routine and
     writing a callback	function, *_poll(), which is invoked to	probe the de-
     vice for events and process them. See the conditionally compiled sections
     of	the devices mentioned above for	more details.

     Because in	the worst case devices are only	polled on clock	interrupts, in
     order to reduce the latency in processing packets it is advisable to in-
     crease the	frequency of the clock to at least 1000	HZ.

     Device polling was	introduced in February 2002 by Luigi Rizzo

BSD			       February	15, 2002			   BSD


Want to link to this manual page? Use this URL:

home | help