从linux源码看epoll前言 在linux的高性能网络编程中,绕不开的就是epoll。和select、poll等系统调用相比,epoll在需要监视大量文件描述符并且其中只有少数活跃的时候,表现出无可比拟的优势。epoll能让内核记住所关注的描述符,并在对应的描述符事件就绪的时候,在epoll的就绪链表中添加这些就绪元素,并唤醒对应的epoll等待进程。本文就是笔者在探究epoll源码过程中,对kernel将就绪描述符添加到epoll并唤醒对应进程的一次源码分析(基于linux2。6。32内核版本)。由于篇幅所限,笔者聚焦于tcp协议下socket可读事件的源码分析。 简单的epoll例子 下面的例子,是从笔者本人用c语言写的dbproxy中的一段代码。由于细节过多,所以做了一些删减。intinitreactor(intlistenfd,intworkercount){ 。。。。。。 创建多个epollfd,以充分利用多核 for(i0;iworkercount;i){ reactorworkerfdepollcreate(EPOLLMAXEVENTS); } epolladdlistenfdandaccept 将accept后的事件加入到对应的epollfd中 intclientfdaccept(listenfd,(structsockaddr)clientaddr,clientlen))); 将连接描述符注册到对应的worker里面 epollctl(reactorclientfd,EPOLLCTLADD,epifd,event); } reactor的worker线程 staticvoidrwthreadfunc(voidarg){ 。。。。。。 for(;;){ epollwait等待事件触发 intretvalepollwait(epfd,events,EPOLLMAXEVENTS,500); if(retval0){ for(j0;jretval;j){ 处理读事件 if(eventEPOLLIN){ handlereadyreadconnection(conn); continue; } 处理其它事件 } } } 。。。。。。 } 上述代码事实上就是实现了一个reactor模式中的accept与readwrite处理线程,如下图所示: epollcreate Unix的万物皆文件的思想在epoll里面也有体现,epollcreate调用返回一个文件描述符,此描述符挂载在anoninodefs(匿名inode文件系统)的根目录下面。让我们看下具体的epollcreate系统调用源码:SYSCALLDEFINE1(epollcreate,int,size) { if(size0) returnEINVAL; returnsysepollcreate1(0); } 由上述源码可见,epollcreate的参数是基本没有意义的,kernel简单的判断是否为0,然后就直接就调用了sysepollcreate1。由于linux的系统调用是通过(SYSCALLDEFINE1,SYSCALLDEFINE2SYSCALLDEFINE6)定义的,那么sysepollcreate1对应的源码即是SYSCALLDEFINE(epollcreate1)。 (注:受限于寄存器数量的限制,(80x86下的)kernel限制系统调用最多有6个参数。据ulk3所述,这是由于32位80x86寄存器的限制) 接下来,我们就看下epollcreate1的源码:SYSCALLDEFINE1(epollcreate1,int,flags) { kzalloc(sizeof(ep),GFPKERNEL),用的是内核空间 errorepalloc(ep); 获取尚未被使用的文件描述符,即描述符数组的槽位 fdgetunusedfdflags(ORDWR(flagsOCLOEXEC)); 在匿名inode文件系统中分配一个inode,并得到其file结构体 且filefopeventpollfops 且fileprivatedataep; fileanoninodegetfile(〔eventpoll〕,eventpollfops,ep, ORDWR(flagsOCLOEXEC)); 将file填入到对应的文件描述符数组的槽里面 fdinstall(fd,file); epfilefile; returnfd; } 最后epollcreate生成的文件描述符如下图所示: structeventpoll 所有的epoll系统调用都是围绕eventpoll结构体做操作,现简要描述下其中的成员: 此结构体存储在fileprivatedata中 structeventpoll{ 自旋锁,在kernel内部用自旋锁加锁,就可以同时多线(进)程对此结构体进行操作 主要是保护readylist spinlocktlock; 这个互斥锁是为了保证在eventloop使用对应的文件描述符的时候,文件描述符不会被移除掉 structmutexmtx; epollwait使用的等待队列,和进程唤醒有关 waitqueueheadtwq; filepoll使用的等待队列,和进程唤醒有关 waitqueueheadtpollwait; 就绪的描述符队列 structlistheadrdllist; 通过红黑树来组织当前epoll关注的文件描述符 structrbrootrbr; 在向用户空间传输就绪事件的时候,将同时发生事件的文件描述符链入到这个链表里面 structepitemovflist; 对应的user structuserstructuser; 对应的文件描述符 structfilefile; 下面两个是用于环路检测的优化 intvisited; structlistheadvisitedlistlink; }; 本文讲述的是kernel是如何将就绪事件传递给epoll并唤醒对应进程上,因此在这里主要聚焦于(waitqueueheadtwq)等成员。 epollctl(add) 我们看下epollctl(EPOLLCTLADD)是如何将对应的文件描述符插入到eventpoll中的。借助于spinlock(自旋锁)和mutex(互斥锁),epollctl调用可以在多个KSE(内核调度实体,即进程线程)中并发执行。SYSCALLDEFINE4(epollctl,int,epfd,int,op,int,fd, structepolleventuser,event) { 校验epfd是否是epoll的描述符 此处的互斥锁是为了防止并发调用epollctl,即保护内部数据结构 不会被并发的添加修改删除破坏 mutexlocknested(epmtx,0); switch(op){ caseEPOLLCTLADD: 。。。 插入到红黑树中 errorepinsert(ep,epds,tfile,fd); 。。。 break; 。。。。。。 } mutexunlock(epmtx); } 上述过程如下图所示: epinsert 在epinsert中初始化了epitem,然后初始化了本文关注的焦点,即事件就绪时候的回调函数,代码如下所示:staticintepinsert(structeventpollep,structepolleventevent, structfiletfile,intfd) { 初始化epitem epq。ptqprocepptablequeueproc initpollfuncptr(epq。pt,epptablequeueproc); 在这里将回调函数注入 reventstfilefoppoll(tfile,epq。pt); 如果当前有事件已经就绪,那么一开始就会被加入到readylist 例如可写事件 另外,在tcp内部ack之后调用tcpcheckspace,最终调用sockdefwritespace来唤醒对应的epollwait下的进程 if((reventseventevents)!epislinked(epirdllink)){ listaddtail(epirdllink,eprdllist); wakeupep对应在epollwait下的进程 if(waitqueueactive(epwq)){ wakeuplocked(epwq); } 。。。。。。 } 将epitem插入红黑树 eprbtreeinsert(ep,epi); 。。。。。。 } tfilefoppoll的实现 向kernel更底层注册回调函数的是tfilefoppoll(tfile,epq。pt)这一句,我们来看一下对于对应的socket文件描述符,其fdfilefoppoll的初始化过程:将accept后的事件加入到对应的epollfd中 intclientfdaccept(listenfd,(structsockaddr)clientaddr,clientlen))); 将连接描述符注册到对应的worker里面 epollctl(reactorclientfd,EPOLLCTLADD,epifd,event); 回顾一下上述userspace代码,fd即clientfd是由tcp的listenfd通过accept调用而来,那么我们看下accept调用链的关键路径:accept accept4 sockattachfd(newsock,newfile,flagsONONBLOCK); initfile(file,。。。,socketfileops); filefopfop; filefopsocketfileops fdinstall(newfd,newfile);安装fd 那么,由accept获得的clientfd的结构如下图所示: (注:由于是tcpsocket,所以这边sockopsinetstreamops,这个初始化的过程在我的另一篇博客从linux源码看socket的阻塞和非阻塞中,博客地址如下: https:my。oschina。netalchemystarblog1791017) 既然知道了tfilefoppoll的实现,我们就可以看下此poll是如何将安装回调函数的。 回调函数的安装 kernel的调用路径如下:sockpolltfilefoppoll(tfile,epq。pt); sockopspoll tcppoll 这边重要的是拿到了sksleep用于KSE(进程线程)的唤醒 sockpollwait(file,sksksleep,wait); pollwait pqproc(filp,waitaddress,p); p为epq。pt,而且epq。ptqprocepptablequeueproc epptablequeueproc(filp,waitaddress,p); 绕了一大圈之后,我们的回调函数的安装其实就是调用了eventpoll。c中的epptablequeueproc,而且向其中传递了sksksleep作为其waitqueue的head,其源码如下所示:staticvoidepptablequeueproc(structfilefile,waitqueueheadtwhead, polltablept) { 取出当前clientfd对应的epitem structepitemepiepitemfromepqueue(pt); pwqwaitfunceppollcallback,用于回调唤醒 注意,这边不是initwaitqueueentry,即没有将当前KSE(current,当前进程线程)写入到 waitqueue当中,因为不一定是从当前安装的KSE唤醒,而应该是唤醒epollwait的KSE initwaitqueuefuncentry(pwqwait,eppollcallback); 这边的whead是sksksleep,将当前的waitqueue链入到socket对应的sleep列表 addwaitqueue(whead,pwqwait); } 这样clientfd的结构进一步完善,如下图所示: eppollcallback函数是唤醒对应epollwait的地方,我们将在后面一起讲述。 epollwait epollwait主要是调用了eppoll:SYSCALLDEFINE4(epollwait,int,epfd,structepolleventuser,events, int,maxevents,int,timeout) { 检查epfd是否是epollcreate创建的fd 调用eppoll erroreppoll(ep,events,maxevents,timeout); 。。。 } 紧接着,我们看下eppoll函数:staticinteppoll(structeventpollep,structepolleventuserevents, intmaxevents,longtimeout) { 。。。。。。 retry: 获取spinlock spinlockirqsave(eplock,flags); 将当前taskstruct写入到waitqueue中以便唤醒 wqentryfuncdefaultwakefunction; initwaitqueueentry(wait,current); WQFLAGEXCLUSIVE,排他性唤醒,配合SOREUSEPORT从而解决accept惊群问题 wait。flagsWQFLAGEXCLUSIVE; 链入到ep的waitqueue中 addwaitqueue(epwq,wait); for(;;){ 设置当前进程状态为可打断 setcurrentstate(TASKINTERRUPTIBLE); 检查当前线程是否有信号要处理,有则返回EINTR if(signalpending(current)){ resEINTR; break; } spinunlockirqrestore(eplock,flags); schedule调度,让出CPU jtimeoutscheduletimeout(jtimeout); spinlockirqsave(eplock,flags); } 到这里,表明超时或者有事件触发等动作导致进程重新调度 removewaitqueue(epwq,wait); 设置进程状态为running setcurrentstate(TASKRUNNING); 。。。。。。 检查是否有可用事件 eavail!listempty(eprdllist)epovflist!EPUNACTIVEPTR; 。。。。。。 向用户空间拷贝就绪事件 epsendevents(ep,events,maxevents) } 上述逻辑如下图所示: epsendevents epsendevents函数主要就是调用了epscanreadylist,顾名思义epscanreadylist就是扫描就绪列表:staticintepscanreadylist(structeventpollep, int(sproc)(structeventpoll, structlisthead,void), voidpriv, intdepth) { 。。。 将epfd的rdllist链入到txlist listspliceinit(eprdllist,txlist); 。。。 sprocepsendeventsproc error(sproc)(ep,txlist,priv); 。。。 处理ovflist,即在上面sproc过程中又到来的事件 。。。 } 其主要调用了epsendeventsproc:staticintepsendeventsproc(structeventpollep,structlistheadhead, voidpriv) { for(eventcnt0,ueventesedevents; !listempty(head)eventcntesedmaxevents;){ 遍历readylist epilistfirstentry(head,structepitem,rdllink); listdelinit(epirdllink); readylist只是表明当前epi有事件,具体的事件信息还是得调用对应file的poll 这边的poll即是tcppoll,根据tcp本身的信息设置掩码(mask)等信息上兴趣事件掩码,则可以得知当前事件是否是epollwait感兴趣的事件 reventsepiffd。filefoppoll(epiffd。file,) epievent。events; if(revents){ 将event放入到用户空间 处理ONESHOT逻辑 如果不是边缘触发,则将当前的epi重新加回到可用列表中,这样就可以下一次继续触发poll,如果下一次poll的revents不为0,那么用户空间依旧能感知 elseif(!(epievent。eventsEPOLLET)){ listaddtail(epirdllink,eprdllist); } 如果是边缘触发,那么就不加回可用列表,因此只能等到下一个可用事件触发的时候才会将对应的epi放到可用列表里面 eventcnt } 如poll出来的revents事件epollwait不感兴趣(或者本来就没有事件),那么也不会加回到可用列表 。。。。。。 } returneventcnt; } 上述代码逻辑如下所示: 事件到来添加到epoll就绪队列(rdllist)的过程 经过上述章节的详述之后,我们终于可以阐述,tcp在数据到来时是怎么加入到epoll的就绪队列的了。 可读事件到来 首先我们看下tcp数据包从网卡驱动到kernel内部tcp协议处理调用链: step1: 网络分组到来的内核路径,网卡发起中断后调用netifrx将事件挂入CPU的等待队列,并唤起软中断(softirq),再通过linux的软中断机制调用netrxaction,如下图所示: 注:上图来自PLKA(深入Linux内核架构) step2: 紧接着跟踪nextrxactionnextrxaction processbacklog 。。。。。。 packettypefunc在这里我们考虑iprcv ipprothandler在这里ipprot重载为tcpprotocol (handler即为tcpv4rcv) 我们再看下对应的tcpv4rcvtcpv4rcv tcpv4dorcv tcprcvstateprocess tcpdataqueue skskdataready(sockdefreadable) wakeupinterruptiblesyncpoll(sksleep,。。。) wakeup wakeupcommon currfunc 这里已经被epinsert添加为eppollcallback,而且设定了排它标识WQFLAGEXCLUSIVE eppollcallback 这样,我们就看下最终唤醒epollwait的eppollcallback函数:staticinteppollcallback(waitqueuetwait,unsignedmode,intsync,voidkey) { 获取wait对应的epitem structepitemepiepitemfromwait(wait); epitem对应的eventpoll结构体 structeventpollepepiep; 获取自旋锁,保护readylist等结构 spinlockirqsave(eplock,flags); 如果当前epi没有被链入ep的readylist,则链入 这样,就把当前的可用事件加入到epoll的可用列表了 if(!epislinked(epirdllink)) listaddtail(epirdllink,eprdllist); 如果有epollwait在等待的话,则唤醒这个epollwait进程 对应的epwq是在epollwait调用的时候通过initwaitqueueentry(wait,current)而生成的 其中的current即是对应调用epollwait的进程信息taskstruct if(waitqueueactive(epwq)) wakeuplocked(epwq); } 上述过程如下图所示: 最后wakeuplocked调用wakeupcommon,然后调用了在initwaitqueueentry注册的defaultwakefunction,调用路径为:wakeuplocked wakeupcommon defaultwakefunction trywakeup(wakeupathread) activatetask enqueuetaskrunning 将epollwait进程推入可运行队列,等待内核重新调度进程,然后epollwait对应的这个进程重新运行后,就从schedule恢复,继续下面的epsendevents(向用户空间拷贝事件并返回)。 wakeup过程如下图所示: 可写事件到来 可写事件的运行过程和可读事件大同小异: 首先,在epollctladd的时候预先会调用一次对应文件描述符的poll,如果返回事件里有可写掩码的时候直接调用wakeuplocked以唤醒对应的epollwait进程。 然后,在tcp在底层驱动有数据到来的时候可能携带了ack从而可以释放部分已经被对端接收的数据,于是触发可写事件,这一部分的调用链为:tcpinput。c tcpv4rcv tcpv4dorcv tcprcvstateprocess tcpdatasndcheck tcpcheckspace tcpnewspace skskwritespace tcp下即是skstreamwritespace 最后在此函数里面skstreamwritespace唤醒对应的epollwait进程voidskstreamwritespace(structsocksk) { 即有13可写空间的时候才触发可写事件 if(skstreamwspace(sk)skstreamminwspace(sk)sock){ clearbit(SOCKNOSPACE,sockflags); if(sksksleepwaitqueueactive(sksksleep)) wakeupinterruptiblepoll(sksksleep,POLLOUT POLLWRNORMPOLLWRBAND) 。。。。。。 } } 关闭描述符(closefd) 值得注意的是,我们在close对应的文件描述符的时候,会自动调用eventpollrelease将对应的file从其关联的epollfd中删除,kernel关键路径如下:closefd filpclose fput fput eventpollrelease epremove 所以我们在关闭对应的文件描述符后,并不需要通过epollctldel来删掉对应epoll中相应的描述符。 学习Linuxkernel源码组好的莫过于ULK3《深入理解Linux内核》 总结 epoll作为linux下非常优秀的事件触发机制得到了广泛的运用。其源码还是比较复杂的,本文只是阐述了epoll读写事件的触发机制,探究linuxkernel源码的过程非常快乐