1.\" 2.\" $FreeBSD: src/share/man/man4/polling.4,v 1.1.2.4 2003/04/14 08:58:02 maxim Exp $ 3.\" $DragonFly: src/share/man/man4/polling.4,v 1.2 2003/06/17 04:36:59 dillon Exp $ 4.\" 5.Dd February 15, 2002 6.Dt POLLING 4 7.Os 8.Sh NAME 9.Nm polling 10.Nd device polling support 11.Sh SYNOPSIS 12.Cd "options DEVICE_POLLING" 13.Cd "options HZ=1000" 14.Sh DESCRIPTION 15.Dq "Device polling" 16(polling for brevity) refers to a technique to 17handle devices that does not rely on the latter to generate 18interrupts when they need attention, but rather lets the CPU poll 19devices to service their needs. 20This might seem inefficient and counterintuitive, but when done 21properly, 22.Nm 23gives more control to the operating system on 24when and how to handle devices, with a number of advantages in terms 25of system responsivity and performance. 26.Pp 27In particular, 28.Nm 29reduces the overhead for context 30switches which is incurred when servicing interrupts, and 31gives more control on the scheduling of the CPU between various 32tasks (user processes, software interrupts, device handling) 33which ultimately reduces the chances of livelock in the system. 34.Sh PRINCIPLES OF OPERATION 35In the normal, interrupt-based mode, devices generate an interrupt 36whenever they need attention. 37This in turn causes a 38context switch and the execution of an interrupt handler 39which performs whatever processing is needed by the device. 40The duration of the interrupt handler is potentially unbounded 41unless the device driver has been programmed with real-time 42concerns in mind (which is generally not the case for 43.Fx 44drivers). 45Furthermore, under heavy traffic, the system might be 46persistently processing interrupts without being able to 47complete other work, either in the kernel or in userland. 48.Pp 49.Nm Polling 50disables interrupts by polling devices at appropriate 51times, i.e., on clock interrupts, system calls and within the idle loop. 52This way, the context switch overhead is removed. 53Furthermore, 54the operating system can control accurately how much work to spend 55in handling device events, and thus prevent livelock by reserving 56some amount of CPU to other tasks. 57.Pp 58.Nm Polling 59is enabled with a 60.Xr sysctl 8 61variable 62.Va kern.polling.enable 63whereas the percentage of CPU cycles reserved to userland processes is 64controlled by the 65.Xr sysctl 8 66variable 67.Va kern.polling.user_frac 68whose range is 0 to 100 (50 is the default value). 69.Pp 70When 71.Nm 72is enabled, and provided that there is work to do, 73up to 74.Va kern.polling.user_frac 75percent of the CPU cycles is reserved to userland tasks, the 76remaining fraction being available for device processing. 77.Pp 78Enabling 79.Nm 80also changes the way network software interrupts 81are scheduled, so there is never the risk of livelock because 82packets are not processed to completion. 83.Pp 84There are other variables which control or monitor the behaviour 85of devices operating in polling mode, but they are unlikely to 86require modifications, and are documented in the source file 87.Pa sys/kern/kern_poll.c . 88.Sh SUPPORTED DEVICES 89.Nm Polling 90requires explicit modifications to the device drivers. 91As of this writing, the 92.Xr dc 4 , 93.Xr em 4 , 94.Xr fxp 4 , 95.Xr rl 4 , 96and 97.Xr sis 4 98devices are supported, with other in the works. 99The modifications are rather straightforward, consisting in 100the extraction of the inner part of the interrupt service routine 101and writing a callback function, 102.Fn *_poll , 103which is invoked 104to probe the device for events and process them. 105See the 106conditionally compiled sections of the devices mentioned above 107for more details. 108.Pp 109Because in the worst case devices are only polled on 110clock interrupts, in order to reduce the latency in processing 111packets, it is advisable to increase the frequency of the clock 112to at least 1000 HZ. 113.Sh HISTORY 114Device polling was introduced in February 2002 by 115.An Luigi Rizzo Aq luigi@iet.unipi.it . 116