Master epoll: Boost Linux Server Performance with Event‑Driven I/O

Introduction

The article revisits the limitations of select and poll for handling many simultaneous connections and introduces epoll , the Linux kernel’s event‑driven I/O multiplexing mechanism that lets the CPU efficiently manage thousands of connections.

What is epoll?

epoll replaces the “poll each descriptor” approach with an event‑notification model: only connections that become ready generate a notification, similar to a customer calling a service desk only when they have a problem.

Why epoll outperforms select/poll

Event‑driven : Resources are used only when an event occurs.

Scalable : No hard limit on the number of file descriptors; it can handle tens of thousands of connections.

Trigger modes : Supports both Level‑Triggered (LT) and Edge‑Triggered (ET) notifications for different performance needs.

epoll’s three‑step workflow

1. Create an epoll instance

Use int epoll_fd = epoll_create(); to obtain an epoll file descriptor that will manage all registered connections.

Internally, epoll stores registered descriptors in a red‑black tree, which provides ordered, self‑balancing storage with O(log N) operations.

int epoll_fd = epoll_create();

2. Register interest (epoll_ctl)

For each socket, fill an epoll_event structure with the desired events (e.g., EPOLLIN) and call epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock_fd, &ev);. This step is analogous to setting a “call me when you have data” rule for each VIP client.

struct epoll_event ev;
ev.events = EPOLLIN;      // monitor readable events
ev.data.fd = sock_fd;          // socket descriptor
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock_fd, &ev);

3. Wait for events (epoll_wait)

Call epoll_wait to block until one or more registered descriptors become ready. Ready descriptors are moved from the red‑black tree to a double‑linked list, allowing the kernel to return only active connections.

struct epoll_event events[10];
int nfds = epoll_wait(epoll_fd, events, 10, -1);
for (int i = 0; i < nfds; ++i) {
    if (events[i].events & EPOLLIN) {
        // handle readable data
    }
}

Trigger modes: LT vs. ET

Level‑Triggered (LT)

LT behaves like a continuously ringing doorbell: as long as data remains unread, epoll_wait keeps notifying the application. This guarantees no data is missed, making it safe for scenarios where the program may read only part of the data at a time.

ev.events = EPOLLIN; // default LT
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock_fd, &ev);

Edge‑Triggered (ET)

ET is a “single‑ring” doorbell: the kernel notifies the application only when the state changes from not‑ready to ready. The program must read all available data in one go, typically using non‑blocking sockets and a read‑loop.

ev.events = EPOLLIN | EPOLLET; // enable ET
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock_fd, &ev);

Choosing the right mode

LT is more reliable because it repeatedly reminds the program of pending data. ET offers higher performance by reducing notification overhead but requires careful handling to avoid data loss.

Pros and cons of epoll

Pros : Scales to large numbers of connections, no fd limit, efficient data structures (red‑black tree + double‑linked list), supports ET for reduced syscalls, avoids copying the entire fd set on each poll.

Cons : Linux‑only (not portable to macOS/Windows), ET mode adds code complexity, long‑lived idle connections still consume memory.

Typical use cases

High‑concurrency web servers, chat services, game servers.

Scenarios requiring fast, event‑driven processing (ET) or guaranteed data handling (LT).

Conclusion

epoll provides a powerful, scalable I/O management solution for Linux servers. By creating an epoll object, registering descriptors, and waiting for events, developers can focus on active connections while the kernel efficiently filters out idle ones. Understanding LT and ET modes allows you to balance reliability and performance for your specific workload.