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