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 an 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(8) variable kern.polling.enable whereas
     the percentage of CPU cycles reserved to userland processes is controlled
     by	the sysctl(8) 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
     kern.polling.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 sys/kern/kern_poll.c.

     Polling requires explicit modifications to	the device drivers.  As	of
     this writing, the dc(4), em(4), fxp(4), rl(4), and	sis(4) 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 device 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