Epoll LT, et model analysis

Original address: http://blog.chinaunix.net/uid-17299695-id-3059078.html

et     lt (level triggered) is the default mode of operation and supports both block and No-block Socket. In this practice, the kernel tells you whether a file descriptor is ready, and then you can do an IO operation on the Ready FD. If you do not do anything, the kernel will continue to notify you, so this mode of programming error is less likely. Traditional Select/poll are the representatives of this model.
    et (edge-triggered) is a high-speed mode of operation that supports only no-block sockets. In this mode, when the descriptor is never ready to be ready, the kernel tells you through Epoll. It then assumes that you know that the file descriptor is ready and no more ready notifications are sent for that file descriptor until you do something that causes the file descriptor to no longer be ready (for example, you are sending, receiving, or receiving requests, Or send received less than a certain amount of data caused by a ewouldblock  error). Note, however, that the kernel does not send more notifications (only once) if the FD is not being used as an IO operation (which causes it to become not ready again), but in the TCP protocol, the Acceleration utility of the ET mode still requires more benchmark acknowledgement.

Usually when you use Epoll, you know that its event trigger mode has the default Level-trigger mode and the Edge-trigger mode enabled by Epollet. From the history of Epoll development, it was born only Edge-trigger mode, and later because it is easy to produce race-cond and not easily understood by developers, but also added Level-trigger mode and as the default processing mode.  The difference between the two is that in Level-trigger mode, whenever an FD is in the readable/writable state, the FD will be returned whenever the epoll_wait is made, whereas in Edge-trigger mode only one FD from unreadable Epoll_wait returns the FD when it becomes readable or changes from unwritable to writable.

The common misconception is that the Level-trigger mode is significantly less efficient than the Edge-trigger mode when there is a large number of FD in the Epoll pool.

However, from the kernel code, the processing logic of the Edge-trigger/level-trigger pattern is almost identical, except that the Level-trigger mode does not remove it from the Ready list when the event occurs, slightly increasing the event The size of the data recorded in kernel space during processing.

However, the Edge-trigger mode must match the Ready list structure in the user app in order to collect the FD that has occurred, and then handle it by Round-robin way, so as to avoid the busy processing hot spot FD when the traffic data is very large, which causes the non-hotspot The phenomenon of FD starvation. Looking at kernel and user space, since the implementation of the Ready list in the user app is not necessarily carefully optimized, the total memory overhead of edge-trigger is often greater than the cost of Level-trigger.

Generally known as the advantage of Edge-trigger mode is to reduce the Epoll related system calls, this is not false, but the user app is not only epoll related system calls it? In order to bypass the starvation problem, Edge-trigger mode of the user app to do their own read/write loop processing, which increases the system calls and reduce the Epoll system calls add up, who can say that must be able to obviously quickly up?

In fact, the efficiency of epoll_wait is O (ready fd num) level, so the real advantage of the edge-trigger pattern is to reduce the number of FD that each epoll_wait may need to return, and to speed up epol when the number of concurrent event is very large L_wait processing speed, but don't forget that this is only for the Epoll system's own elevation, while the user app needs to add complex logic, spend more cpu/mem and work with it, the overall performance benefits? Only the actual measurement will know, can not generalize. However, in order to reduce the complexity of processing logic, most of the commonly used event processing libraries have chosen Level-trigger mode (such as libevent, Boost::asio, etc.)

Conclusion:
Epoll the Edge-trigger and Level-trigger pattern processing logic difference is very small, the performance test results show that the performance difference can be neglected in conventional application scenarios, the user app using Edge-trigger is more than the logic of Level-trigger Edge-trigger and Level-trigger performance differences are mainly in the epoll_wait system call processing speed, whether the user app performance bottleneck needs to depend on the application scenario, not generalize.

Epoll LT, et mode analysis (RPM)