Summary of differences between SELECT, poll and Epoll [finishing]

Summary of differences between SELECT, poll and Epoll [finishing]

The select,poll,epoll is a mechanism for IO multiplexing. I/O multiplexing is a mechanism by which multiple descriptors can be monitored, and once a descriptor is ready (usually read-ready or write-ready), the program can be notified of the appropriate read and write operations. But select,poll,epoll are essentially synchronous I/O, because they all need to read and write when the read-write event is ready, that is, the read-write process is blocked , and asynchronous I/O does not have to be responsible for reading and writing, asynchronous i/ The implementation of O is responsible for copying the data from the kernel to the user space. With regard to the usage of these three IO multiplexing, the previous three summaries were very clear and were tested with the server-back echo program. The connection is as follows:

Select:http://www.cnblogs.com/anker/archive/2013/08/14/3258674.html

Poll:http://www.cnblogs.com/anker/archive/2013/08/15/3261006.html

Epoll:http://www.cnblogs.com/anker/archive/2013/08/17/3263780.html

Today, compare these three kinds of IO multiplexing, referring to the information on the Internet and on the books, and organize the following:

1. Select implementation

The call procedure for select is as follows:

(1) using Copy_from_user to copy fd_set from user space to kernel space

(2) Register callback function __pollwait

(3) Traverse all FD, call its corresponding poll method (for socket, this poll method is sock_poll,sock_poll according to the situation will call to Tcp_poll,udp_poll or Datagram_poll)

(4) Taking Tcp_poll as an example, its core implementation is __pollwait, which is the callback function registered above.

(5) The main task of __pollwait is to hang the current process into the waiting queue of the device, different devices have different waiting queues, and for Tcp_poll, their waiting queue is sk->sk_ Sleep (note that suspending the process to the waiting queue does not mean that the process is already asleep). When the device receives a message (network device) or fills out the file data (disk device), it wakes the device to wait for the sleep process on the queue, and current is awakened.

(6) The poll method returns a mask mask that describes whether the read-write operation is ready and assigns a value to fd_set based on the mask mask.

(7) If all FD is traversed and no read-write mask is returned, the call to Schedule_timeout is the process that calls select (that is, current) into sleep. When a device driver takes its own resource to read and write, it wakes up the process of waiting for sleep on the queue. If there is more than a certain timeout (schedule_timeout specified), or no one wakes up, then the process calling select will be woken up to get the CPU again, and then iterate over the FD to determine if there is no ready FD.

(8) Copy the fd_set from the kernel space to the user space.

Summarize:

A few of the major drawbacks of select:

(1) Each call to select, the FD collection needs to be copied from the user state to the kernel state, the cost of FD is very large

(2) At the same time, each call to select requires a kernel traversal of all the FD passed in, which is also very expensive when FD is very large

(3) The number of file descriptors supported by Select is too small, the default is 1024

2 Poll Implementation

The implementation of poll is very similar to select, except that it describes the FD collection in different ways, poll uses the POLLFD structure rather than the fd_set structure of the Select, and the others are the same.

For the implementation analysis of select and poll, refer to the following blog posts:

Http://blog.csdn.net/lizhiguo0532/article/details/6568964#comments

http://blog.csdn.net/lizhiguo0532/article/details/6568968

http://blog.csdn.net/lizhiguo0532/article/details/6568969

http://www.ibm.com/developerworks/cn/linux/l-cn-edntwk/index.html?ca=drs-

Http://linux.chinaunix.net/techdoc/net/2009/05/03/1109887.shtml

3, Epoll

Since Epoll is an improvement on select and poll, the above three drawbacks should be avoided. How did that epoll all work out? Before we take a look at the different invocation interfaces of Epoll and select and poll, both Select and poll provide only a function--select or poll function. While Epoll provides three functions, Epoll_create,epoll_ctl and Epoll_wait,epoll_create are created with a epoll handle; Epoll_ctl is the type of event registered to listen; Epoll_ Wait is waiting for the event to occur.

For the first drawback, the Epoll solution is in the Epoll_ctl function. Each time a new event is registered in the Epoll handle (specifying Epoll_ctl_add in Epoll_ctl), all FD is copied into the kernel instead of being duplicated at epoll_wait. Epoll guarantees that each FD will be copied only once throughout the process.

For the second disadvantage, the solution for Epoll is not to add current to the FD-corresponding device-waiting queue each time, like Select or poll, but to hang the current only once at Epoll_ctl (which is necessary) and to specify a callback function for each FD. This callback function is invoked when the device is ready to wake the waiting queue, and the callback function will add the ready FD to a ready list. Epoll_wait's job is actually to see if there is a ready-to-use FD (using Schedule_timeout () to sleep for a while, judging the effect of a meeting, and the 7th step in the Select implementation is similar).

For the third disadvantage, Epoll does not have this limit, it supports the maximum number of FD can open file, this number is generally far greater than 2048, for example, in 1GB memory of the machine is about 100,000, the exact number can cat/proc/sys/fs/ File-max, in general, this number and system memory relationship is very large.

Summarize:

(1) The Select,poll implementation requires itself to constantly poll all FD collections until the device is ready, during which time the sleep and wake-up cycles may be repeated. While Epoll actually needs to call Epoll_wait to constantly poll the ready linked list, there may be multiple sleep and wake alternates, but when it is device ready, call the callback function, put the ready FD into the Ready list, and wake the process into sleep in epoll_wait. While both sleep and alternate, select and poll traverse the entire FD collection while "Awake", while Epoll is "awake" as long as it is OK to determine if the ready list is empty, which saves a lot of CPU time. This is the performance boost that the callback mechanism brings.

(2) Select,poll each call to the FD set from the user state to the kernel state copy once, and to the device to wait for the queue to hang once, and epoll as long as a copy, and the current to wait for the queue is hung only once (in Epoll_ At the start of wait, note that the wait queue here is not the device waiting queue, just a epoll internally defined wait queue. This can also save a lot of overhead.

Resources:

Http://www.cnblogs.com/apprentice89/archive/2013/05/09/3070051.html

Http://www.linuxidc.com/Linux/2012-05/59873p3.htm

http://xingyunbaijunwei.blog.163.com/blog/static/76538067201241685556302/

http://blog.csdn.net/kkxgx/article/details/7717125

Https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/epoll-example.c

Http://www.embeddedlinux.org.cn/html/yingjianqudong/201303/11-2477.html

Summary of differences between SELECT, poll and Epoll [finishing]