How Epoll Saves Processes from Endless Polling: A Story of Linux I/O

01

A process, personified as "little P", is created and managed by the operating system kernel. It runs in user mode while most kernel components stay in kernel mode, and the process has no direct access to hardware such as disks or network cards.

When a process needs hardware functionality, it must invoke a system call, which transitions execution into kernel mode after a strict security check.

02

Network communication is performed through sockets. The process only sees a socket descriptor; the kernel owns the actual socket and all network packets.

Historically, a process handled a single TCP connection using the recvfrom system call. If data was not ready, the call would block, forcing the process to yield the CPU.

When workloads grew to hundreds or thousands of connections, blocking on each read became a severe bottleneck: the process spent time saving state and wasted cache, and frequent context switches reduced throughput.

The solution was to set sockets to non‑blocking mode, allowing the process to poll sockets in a loop without being suspended.

However, without a way to know when data arrives, the process still had to repeatedly query the kernel, leading to wasted CPU cycles.

03

The kernel introduced multiplexing system calls: select, poll, and the more efficient epoll. Epoll maintains an internal red‑black tree of watched sockets.

With epoll, the process registers its sockets once and then calls epoll_wait. The kernel returns only the sockets that have pending events, eliminating constant polling.

When many connections are active, epoll can continuously deliver ready sockets without blocking. In a Redis benchmark, this approach achieved up to 100,000 QPS.

When no sockets have data, the process can safely block, freeing the CPU until the kernel wakes it via a soft interrupt.

Upon receiving a network packet, a soft‑interrupt handler places the process back onto the epoll wait queue, and the scheduler later selects it for execution.

This collaboration between the process, epoll, soft interrupts, and the scheduler demonstrates how kernel‑level I/O multiplexing dramatically improves efficiency and scalability.