The Linux Programming Interface

Alternative I/O Models 1365

63.4.5 Performance of epoll Versus I/O Multiplexing

Table 63-9 shows the results (on Linux 2.6.25) when we monitor N contiguous file

descriptors in the range 0 to N – 1 using poll(), select(), and epoll. (The test was

arranged such that during each monitoring operation, exactly one randomly

selected file descriptor is ready.) From this table, we see that as the number of file

descriptors to be monitored grows large, poll() and select() perform poorly. By con-

trast, the performance of epoll hardly declines as N grows large. (The small decline

in performance as N increases is possibly a result of reaching CPU caching limits on

the test system.)

For the purposes of this test, FD_SETSIZE was changed to 16,384 in the glibc

header files to allow the test program to monitor large numbers of file descrip-

tors using select().

In Section 63.2.5, we saw why select() and poll() perform poorly when monitoring large

numbers of file descriptors. We now look at the reasons why epoll performs better:

z On each call to select() or poll(), the kernel must check all of the file descriptors

specified in the call. By contrast, when we mark a descriptor to be monitored

with epoll_ctl(), the kernel records this fact in a list associated with the underlying

open file description, and whenever an I/O operation that makes the file

descriptor ready is performed, the kernel adds an item to the ready list for the

epoll descriptor. (An I/O event on a single open file description may cause

multiple file descriptors associated with that description to become ready.) Subse-

quent epoll_wait() calls simply fetch items from the ready list.

z Each time we call select() or poll(), we pass a data structure to the kernel that

identifies all of the file descriptors that are to be monitored, and, on return,

the kernel passes back a data structure describing the readiness of all of these

descriptors. By contrast, with epoll, we use epoll_ctl() to build up a data struc-

ture in kernel space that lists the set of file descriptors to be monitored. Once

this data structure has been built, each later call to epoll_wait() doesn’t need to

pass any information about file descriptors to the kernel, and the call returns

information about only those descriptors that are ready.

In addition to the above points, for select(), we must initialize the input data

structure prior to each call, and for both select() and poll(), we must inspect the

returned data structure to find out which of the N file descriptors are ready.

However, some testing showed that the time required for these other steps was

Table 63-9: Times taken by poll(), select(), and epoll for 100,000 monitoring operations

Number of descriptors

monitored (N)

poll() CPU time

(seconds)

select() CPU time

(seconds)

epoll CPU time

(seconds)

10 0.61 0.73 0.41

100 2.9 3.0 0.42

1000 35 35 0.53

10000 990 930 0.66