Epoll详解及源码分析

epoll是当前在Linux下开发大规模并发网络程序的热门人选，epoll 在Linux2.6内核中正式引入，和select相似，都是I/O多路复用(IO multiplexing)技术,按照man手册的说法：是为处理大批量句柄而作了改进的poll。

Linux下有以下几个经典的服务器模型：

 

①Apache模型（Process Per Connection，简称PPC） 和 TPC（Thread Per Connection）模型

这两种模型思想类似，就是让每一个到来的连接都有一个进程/线程来服务。这种模型的代价是它要时间和空间。连接较多时，进程/线程切换的开销比较大。因此这类模型能接受的最大连接数都不会高，一般在几百个左右。

 

②select模型

最大并发数限制：因为一个进程所打开的fd（文件描述符）是有限制的，由FD_SETSIZE设置，默认值是1024/2048，因此select模型的最大并发数就被相应限制了。下载

效率问题：select每次调用都会线性扫描全部的fd集合，这样效率就会呈现线性下降，把FD_SETSIZE改大可能造成这些fd都超时了。

内核/用户空间内存拷贝问题：如何让内核把fd消息通知给用户空间呢？在这个问题上select采取了内存拷贝方法。

 

③poll模型

虽然解决了select 最大并发数的限制，但是依然存在select的效率问题，select缺点的2和3它都没有改掉。

 

④epoll模型

对比其他模型的问题，epoll的改进如下：下载

1.支持一个进程打开大数目的socket描述符(FD)
    select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完 美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
 
     2.IO效率不随FD数目增加而线性下降
    传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的， 但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行 操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相 反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
 
3.使用mmap加速内核与用户空间的消息传递下载
    这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就 很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工 mmap这一步的。
 
4.内核微调
      这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。 比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小 --- 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手 的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网 卡驱动架构。
 

2.Epoll API下载

epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。

   1: #include  <sys/epoll.h>

   2: 

   3: int  epoll_create(int  size);

   4: 

   5: int  epoll_ctl(int epfd, int op, int fd, structepoll_event *event);

   6: 

   7: int  epoll_wait(int epfd, struct epoll_event* events, int maxevents. int timeout);

   8: 

   9: 

① int epoll_create(int size);

创建一个epoll的句柄。自从linux2.6.8之后，size参数是被忽略的。需要注意的是，当创建好epoll句柄后，它就是会占用一个 fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能 导致fd被耗尽。

②int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数，它不同于select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。
第一个参数是epoll_create()的返回值。
第二个参数表示动作，用三个宏来表示：
EPOLL_CTL_ADD：注册新的fd到epfd中；
EPOLL_CTL_MOD：修改已经注册的fd的监听事件；
EPOLL_CTL_DEL：从epfd中删除一个fd；
 
第三个参数是需要监听的fd。
第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：下载

   1: //保存触发事件的某个文件描述符相关的数据（与具体使用方式有关）

   2: 

   3: typedef union epoll_data {

   4:     void *ptr;

   5:     int fd;

   6:     __uint32_t u32;

   7:     __uint64_t u64;

   8: } epoll_data_t;

   9:  //感兴趣的事件和被触发的事件

  10: struct epoll_event {

  11:     __uint32_t events; /* Epoll events */

  12:     epoll_data_t data; /* User data variable */

  13: };

events可以是以下几个宏的集合：
EPOLLIN ：表示对应的文件描述符可以读（包括对端SOCKET正常关闭）；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

③ int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

收集在epoll监控的事件中已经发送的事件。参数events是分配好的epoll_event结构体数组，epoll将会把发生的事件赋值到 events数组中（events不可以是空指针，内核只负责把数据复制到这个events数组中，不会去帮助我们在用户态中分配内存）。 maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有 说法说是永久阻塞）。如果函数调用成功，返回对应I/O上已准备好的文件描述符数目，如返回0表示已超时。下载

3.Epoll  工作模式

①LT模式：Level Triggered水平触发

这个是缺省的工作模式。同时支持block socket和non-block socket。内核会告诉程序员一个文件描述符是否就绪了。如果程序员不作任何操作，内核仍会通知。

 

②ET模式：Edge Triggered 边缘触发

是一种高速模式。仅当状态发生变化的时候才获得通知。这种模式假定程序员在收到一次通知后能够完整地处理事件，于是内核不再通知这一事件。注意：缓 冲区中还有未处理的数据不算状态变化，所以ET模式下程序员只读取了一部分数据就再也得不到通知了，正确的用法是程序员自己确认读完了所有的字节（一直调 用read/write直到出错EAGAIN为止）。

 

如下图：

0：表示文件描述符未准备就绪

1：表示文件描述符准备就绪

 

对于水平触发模式(LT)：在1处，如果你不做任何操作，内核依旧会不断的通知进程文件描述符准备就绪。

对于边缘出发模式(ET): 只有在0变化到1处的时候，内核才会通知进程文件描述符准备就绪。之后如果不在发生文件描述符状态变化，内核就不会再通知进程文件描述符已准备就绪。

 

Nginx 默认采用的就是ET。

 

 

4.实例下载

 

   1: #include <stdio.h>

   2: #include <stdlib.h>

   3: #include <unistd.h>

   4: #include <sys/socket.h>

   5: #include <errno.h>

   6: #include <sys/epoll.h>

   7: #include <netinet/in.h>

   8: #include <fcntl.h>

   9: #include <string.h>

  10:  #include <netdb.h>

  11: 

  12: 

  13: 

  14: struct epoll_event  *events = NULL;

  15: int epollFd = -1;

  16: 

  17: const int MAX_SOCK_NUM = 1024;

  18: 

  19: 

  20: int epoll_init();

  21: int epoll_socket(int domain, int type, int protocol);

  22: int epoll_cleanup();

  23: int epoll_new_conn(int sfd);

  24: 

  25: 

  26: int main()

  27: {

  28:       struct sockaddr_in listenAddr;

  29:       int listenFd = -1;

  30: 

  31:       if(-1 == epoll_init())

  32:       {

  33:           printf("epoll_init err\n");

  34:           return -1;

  35:       }

  36: 

  37:       if((listenFd = epoll_socket(AF_INET,SOCK_STREAM,0)) == -1)

  38:       {

  39:           printf("epoll_socket err\n");

  40:           epoll_cleanup();

  41:           return -1;

  42:       }

  43: 

  44:       listenAddr.sin_family = AF_INET;

  45:       listenAddr.sin_port = htons(999);

  46:       listenAddr.sin_addr.s_addr = htonl(INADDR_ANY);

  47: 

  48:       if(-1 == bind(listenFd,(struct sockaddr*)&listenAddr,sizeof(listenAddr)))

  49:       {

  50:           printf("bind err %d\n",errno);

  51:           epoll_cleanup();

  52:           return -1;

  53:       }

  54: 

  55:       if(-1 == listen(listenFd,1024))

  56:       {

  57:           printf("listen err\n");

  58:           epoll_cleanup();

  59:           return -1;

  60:       }

  61: 

  62:       //Add ListenFd into epoll

  63:       if(-1 == epoll_new_conn(listenFd))

  64:       {

  65:           printf("eph_new_conn err\n");

  66:           close(listenFd);

  67:         epoll_cleanup();

  68:         return -1;

  69:       }

  70: 

  71: 

  72:       //LOOP

  73:       while(1)

  74:       {

  75:           int n;

  76:           n = epoll_wait(epollFd,events,MAX_SOCK_NUM,-1);

  77:           for (int i = 0; i < n; i++)

  78:           {

  79:                if( (events[i].events & EPOLLERR) || ( events[i].events & EPOLLHUP ) || !(events[i].events & EPOLLIN) )

  80:                {

  81:                    printf("epoll err\n");

  82:                    close(events[i].data.fd);

  83:                    continue;

  84:                }

  85:                else if(events[i].data.fd == listenFd)

  86:                {

  87:                    while(1)

  88:                    {

  89:                        struct sockaddr inAddr;

  90:                        char hbuf[1024],sbuf[NI_MAXSERV];

  91:                        socklen_t inLen = -1;

  92:                        int inFd = -1;

  93:                        int s = 0;

  94:                        int flag = 0;

  95: 

  96:                        inLen = sizeof(inAddr);

  97:                        inFd = accept(listenFd,&inAddr,&inLen);

  98: 

  99:                        if(inFd == -1)

 100:                        {

 101:                            if( errno == EAGAIN || errno == EWOULDBLOCK )

 102:                            {

 103:                                break;

 104:                            }

 105:                            else

 106:                            {

 107:                                printf("accept error\n");

 108:                                break;

 109:                            }

 110:                        }

 111: 

 112:                     if (s ==  getnameinfo (&inAddr, inLen, hbuf, sizeof(hbuf), sbuf, sizeof(sbuf), NI_NUMERICHOST | NI_NUMERICSERV))

 113:                     {

 114:                         printf("Accepted connection on descriptor %d (host=%s, port=%s)\n", inFd, hbuf, sbuf);

 115:                     }

 116: 

 117:                     //Set Socket to non-block

 118:                     if((flag = fcntl(inFd,F_GETFL,0)) < 0 || fcntl(inFd,F_SETFL,flag | O_NONBLOCK) < 0)

 119:                     {

 120:                         close(inFd);

 121:                         return -1;

 122:                     }

 123: 

 124:                     epoll_new_conn(inFd);

 125:                    }

 126:                }

 127:                else

 128:                {

 129:                         while (1)

 130:                         {

 131:                         ssize_t count;

 132:                         char buf[512];

 133: 

 134:                         count = read (events[i].data.fd, buf, sizeof buf);

 135: 

 136:                         if (count == -1)

 137:                         {

 138:                             if (errno != EAGAIN)

 139:                              {

 140:                                 printf("read err\n");

 141:                                 }

 142: 

 143:                             break;

 144: 

 145:                         }

 146:                         else if (count == 0)

 147:                         { 

 148:                             break;

 149:                         }

 150: 

 151:                         write (1, buf, count);

 152:                     }

 153:                 }

 154:           }

 155: 

 156:       }

 157: 

 158:       epoll_cleanup();

 159: }

 160: 

 161: 

 162: int epoll_init()

 163: {

 164:     if(!(events = (struct epoll_event* ) malloc ( MAX_SOCK_NUM * sizeof(struct epoll_event))))

 165:     {

 166:         return -1;

 167:     }

 168: 

 169:     if( (epollFd = epoll_create(MAX_SOCK_NUM)) < 0 )

 170:     {

 171:         return -1;

 172:     }

 173: 

 174:     return 0;

 175: }

 176: 

 177: int epoll_socket(int domain, int type, int protocol)

 178: {

 179:     int sockFd = -1;

 180:     int flag = -1;

 181: 

 182:     if ((sockFd = socket(domain,type,protocol)) < 0)

 183:     {

 184:         return -1;

 185:     }

 186: 

 187:     //Set Socket to non-block

 188:     if((flag = fcntl(sockFd,F_GETFL,0)) < 0 || fcntl(sockFd,F_SETFL,flag | O_NONBLOCK) < 0)

 189:     {

 190:         close(sockFd);

 191:         return -1;

 192:     }

 193: 

 194:     return sockFd;

 195: }

 196: 

 197: int epoll_cleanup()

 198: {

 199:     free(events);

 200:     close(epollFd);

 201:     return 0;

 202: }

 203: 

 204: int epoll_new_conn(int sfd)

 205: {

 206: 

 207:       struct epoll_event  epollEvent;

 208:       memset(&epollEvent, 0, sizeof(struct epoll_event));

 209:       epollEvent.events = EPOLLIN | EPOLLERR | EPOLLHUP | EPOLLET;

 210:       epollEvent.data.ptr = NULL;

 211:       epollEvent.data.fd  = sfd;

 212: 

 213:       if (epoll_ctl(epollFd, EPOLL_CTL_ADD, sfd, &epollEvent) < 0)

 214:       {

 215:         return -1;

 216:       }

 217: 

 218:     epollEvent.data.fd  = sfd;

 219: 

 220:     return 0;

 221: }

 

 

5.Epoll为什么高效

Epoll高效主要体现在以下三个方面：下载

①从上面的调用方式就可以看出epoll比select/poll的一个优势：select/poll每次调用都要传递所要监控的所有fd给 select/poll系统调用（这意味着每次调用都要将fd列表从用户态拷贝到内核态，当fd数目很多时，这会造成低效）。而每次调用 epoll_wait时（作用相当于调用select/poll），不需要再传递fd列表给内核，因为已经在epoll_ctl中将需要监控的fd告诉了 内核（epoll_ctl不需要每次都拷贝所有的fd，只需要进行增量式操作）。所以，在调用epoll_create之后，内核已经在内核态开始准备数 据结构存放要监控的fd了。每次epoll_ctl只是对这个数据结构进行简单的维护。

 

② 此外，内核使用了slab机制，为epoll提供了快速的数据结构：

在内核里，一切皆文件。所以，epoll向内核注册了一个文件系统，用于存储上述的被监控的fd。当你调用 epoll_create时，就会在这个虚拟的epoll文件系统里创建一个file结点。当然这个file不是普通文件，它只服务于epoll。 epoll在被内核初始化时（操作系统启动），同时会开辟出epoll自己的内核高速cache区，用于安置每一个我们想监控的fd，这些fd会以红黑树的形式保存在内核cache里，以支持快速的查找、插入、删除。这个内核高速cache区，就是建立连续的物理内存页，然后在之上建立slab层，简单的说，就是物理上分配好你想要的size的内存对象，每次使用时都是使用空闲的已分配好的对象。

 

③ epoll的第三个优势在于：当我们调用epoll_ctl往里塞入百万个fd时，epoll_wait仍然可以飞快的返回，并有效的将发生事件的fd给我们用户。这 是由于我们在调用epoll_create时，内核除了帮我们在epoll文件系统里建了个file结点，在内核cache里建了个红黑树用于存储以后 epoll_ctl传来的fd外，还会再建立一个list链表，用于存储准备就绪的事件，当epoll_wait调用时，仅仅观察这个list链表里有没 有数据即可。有数据就返回，没有数据就sleep，等到timeout时间到后即使链表没数据也返回。所以，epoll_wait非常 高效。而且，通常情况下即使我们要监控百万计的fd，大多一次也只返回很少量的准备就绪fd而已，所以，epoll_wait仅需要从内核态copy少量 的fd到用户态而已。那么，这个准备就绪list链表是怎么维护的呢？当我们执行epoll_ctl时，除了把fd放到epoll文件系统里file对象 对应的红黑树上之外，还会给内核中断处理程序注册一个回调函数，告诉内核，如果这个fd的中断到了，就把它放到准备就绪list链表里。所以，当一个 fd（例如socket）上有数据到了，内核在把设备（例如网卡）上的数据copy到内核中后就来把fd（socket）插入到准备就绪list链表里 了。

如此，一颗红黑树，一张准备就绪fd链表，少量的内核cache，就帮我们解决了大并发下的fd（socket）处理问题。下载

1.执行epoll_create时，创建了红黑树和就绪list链表。

2.执行epoll_ctl时，如果增加fd（socket），则检查在红黑树中是否存在，存在立即返回，不存在则添加到红黑树上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪list链表中插入数据。

3.执行epoll_wait时立刻返回准备就绪链表里的数据即可。

6.Epoll源码分析下载

 

   1: static int __init eventpoll_init(void)

   2: {

   3:   mutex_init(&pmutex);

   4: 

   5:   ep_poll_safewake_init(&psw);

   6: 

   7:   epi_cache = kmem_cache_create("eventpoll_epi", sizeof(struct epitem), 0, SLAB_HWCACHE_ALIGN|EPI_SLAB_DEBUG|SLAB_PANIC, NULL);

   8: 

   9:   pwq_cache = kmem_cache_create("eventpoll_pwq", sizeof(struct eppoll_entry), 0, EPI_SLAB_DEBUG|SLAB_PANIC, NULL);

  10: 

  11:   return 0;

  12: }

 

epoll用kmem_cache_create（slab分配器）分配内存用来存放struct epitem和struct eppoll_entry。

 

当向系统中添加一个fd时，就创建一个epitem结构体，这是内核管理epoll的基本数据结构：

   1: struct epitem

   2: {

   3:     struct rb_node  rbn;        //用于主结构管理的红黑树

   4: 

   5:     struct list_head  rdllink;  //事件就绪队列

   6: 

   7:     struct epitem  *next;       //用于主结构体中的链表

   8: 

   9:     struct epoll_filefd  ffd;   //这个结构体对应的被监听的文件描述符信息

  10: 

  11:     int  nwait;                 //poll操作中事件的个数

  12: 

  13:     struct list_head  pwqlist;  //双向链表，保存着被监视文件的等待队列，功能类似于select/poll中的poll_table

  14: 

  15:     struct eventpoll  *ep;      //该项属于哪个主结构体（多个epitm从属于一个eventpoll）

  16: 

  17:     struct list_head  fllink;   //双向链表，用来链接被监视的文件描述符对应的struct file。因为file里有f_ep_link,用来保存所有监视这个文件的epoll节点

  18: 

  19:     struct epoll_event  event;  //注册的感兴趣的事件,也就是用户空间的epoll_event

  20: 

  21: }

 

而每个epoll fd（epfd）对应的主要数据结构为：

   1: struct eventpoll

   2: {

   3:     spin_lock_t       lock;             //对本数据结构的访问

   4: 

   5:     struct mutex      mtx;              //防止使用时被删除

   6: 

   7:     wait_queue_head_t     wq;           //sys_epoll_wait() 使用的等待队列

   8: 

   9:     wait_queue_head_t   poll_wait;      //file->poll()使用的等待队列

  10: 

  11:     struct list_head    rdllist;        //事件满足条件的链表

  12: 

  13:     struct rb_root      rbr;            //用于管理所有fd的红黑树（树根）

  14: 

  15:     struct epitem      *ovflist;       //将事件到达的fd进行链接起来发送至用户空间

  16: 

  17: }

  18: 

 

eventpoll在epoll_create时创建:下载

   1: long sys_epoll_create(int size)

   2: {

   3: 

   4:     struct eventpoll *ep;

   5: 

   6:     ...

   7: 

   8:     ep_alloc(&ep); //为ep分配内存并进行初始化

   9: 

  10: /* 调用anon_inode_getfd 新建一个file instance，也就是epoll可以看成一个文件（匿名文件）。因此我们可以看到epoll_create会返回一个fd。epoll所管理的所有的fd都是放在一个大的结构eventpoll(红黑树)中，

  11: 将主结构体struct eventpoll *ep放入file->private项中进行保存（sys_epoll_ctl会取用）*/

  12: 

  13:  fd = anon_inode_getfd("[eventpoll]", &eventpoll_fops, ep, O_RDWR | (flags & O_CLOEXEC));

  14: 

  15:      return fd;

  16: 

  17: }

 

其中，ep_alloc(struct eventpoll **pep)为pep分配内存，并初始化。

其中，上面注册的操作eventpoll_fops定义如下：

   1: static const struct file_operations eventpoll_fops = {

   2: 

   3:     .release=  ep_eventpoll_release,

   4: 

   5:     .poll    =  ep_eventpoll_poll,

   6: 

   7: };

 

这样说来，内核中维护了一棵红黑树，大致的结构如下：