poll及epoll内核实现分析

作者：董昊 （要转载的同学帮忙把名字和博客链接http://donghao.org/uii/带上，多谢了！)

epoll原理简介原理简介

通过上面的分析，poll运行效率的两个瓶颈已经找出，现在的问题是怎么改进。首先，每次poll都要把

1000个fd 拷入内核，太不科学了，内核干嘛不自己保存已经拷入的fd呢？答对了，epoll就是自己保存拷

入的fd，它的API就已经说明了这一点——不是 epoll_wait的时候才传入fd，而是通过epoll_ctl把所有fd

传入内核再一起"wait"，这就省掉了不必要的重复拷贝。其次，在 epoll_wait时，也不是把current轮流

的加入fd对应的设备等待队列，而是在设备等待队列醒来时调用一个回调函数（当然，这就需要“唤醒回

调”机制），把产生事件的fd归入一个链表，然后返回这个链表上的fd。

epoll剖析剖析

1586 init_MUTEX(&epsem);

1587

1588 /* Initialize the structure used to perform safe poll wait head wake ups */

1589 ep_poll_safewake_init(&psw);

1590

1591 /* Allocates slab cache used to allocate "struct epitem" items */

1592 epi_cache = kmem_cache_create("eventpoll_epi", sizeof(struct epitem),

1593 0, SLAB_HWCACHE_ALIGN|EPI_SLAB_DEBUG|SLAB_PANIC,

1594 NULL, NULL);

1595

1602 * Register the virtual file system that will be the source of inodes

1603 * for the eventpoll files

1604 */

1605 error = register_filesystem(&eventpoll_fs_type);

1606 if (error)

1607 goto epanic;

1608

1609 /* Mount the above commented virtual file system */

1610 eventpoll_mnt = kern_mount(&eventpoll_fs_type);

1611 error = PTR_ERR(eventpoll_mnt);

1618

1619 epanic:

1620 panic("eventpoll_init() failed\n");

1621 }

很有趣，这个module在初始化时注册了一个新的文件系统，叫"eventpollfs"（在eventpoll_fs_type结

构里），然后挂载此文 件系统。另外创建两个内核cache（在内核编程中，如果需要频繁分配小块内存，

应该创建kmem_cahe来做“内存池”）,分别用于存放struct epitem和eppoll_entry。如果以后要开发新

的文件系统，可以参考这段代码。

现在想想epoll_create为什么会返回一个新的fd？因为它就是在这个叫做"eventpollfs"的文件系统里创建

了一个新文件！如下：

481

482 DNPRINTK(3, (KERN_INFO "[%p] eventpoll: sys_epoll_create(%d)\n",

483 current, size));

484

485 /* Sanity check on the size parameter */

486 error = -EINVAL;

487 if (size <= 0)

488 goto eexit_1;

489

490 /*

497

498 /* Setup the file internal data structure ( "struct eventpoll" ) */

499 error = ep_file_init(file);

500 if (error)

501 goto eexit_2;

函数很简单，其中ep_getfd看上去是“get”，其实在第一次调用epoll_create时，它是要创建新inode、

新的file、新的fd。而ep_file_init则要创建一个struct eventpoll结构，并把它放入file-

>private_data，注意，这个private_data后面还要用到的。

看到这里，也许有人要问了，为什么epoll的开发者不做一个内核的超级大map把用户要创建的epoll句柄

存起来，在epoll_create时返回一个指针？那似乎很直观呀。但是，仔细看看，linux的系统调用有多少是

epoll_create好了，该epoll_ctl了，我们略去判断性的代码：

[fs/eventpoll.c-->sys_epoll_ctl()]

524 asmlinkage long

525 sys_epoll_ctl(int epfd, int op, int fd, struct epoll_event __user *event)

526 {

527 int error;

528 struct file *file, *tfile;

529 struct eventpoll *ep;

530 struct epitem *epi;

531 struct epoll_event epds;

....

575 epi = ep_find(ep, tfile, fd);

576

583 error = ep_insert(ep, &epds, tfile, fd);

584 } else

585 error = -EEXIST;

586 break;

587 case EPOLL_CTL_DEL:

588 if (epi)

589 error = ep_remove(ep, epi);

590 else

591 error = -ENOENT;

592 break;

599 break;

600 }

原来就是在一个大的结构（现在先不管是什么大结构）里先ep_find，如果找到了struct epitem而用户操

作是ADD，那么返回-EEXIST；如果是DEL，则ep_remove。如果找不到struct epitem而用户操作是

ADD，就ep_insert创建并插入一个。很直白。那这个“大结构”是什么呢？看ep_find的调用方式，ep参数

应该是指向这个“大结构”的指针，再看ep = file->private_data，我们才明白，原来这个“大结构”就是那

个在epoll_create时创建的struct eventpoll，具体再看看ep_find的实现，发现原来是struct eventpoll

的rbr成员（struct rb_root），原来这是一个红黑树的根！而红黑树上挂的都是struct epitem。

现在清楚了，一个新创建的epoll文件带有一个struct eventpoll结构，这个结构上再挂一个红黑树，而这

个红黑树就是每次epoll_ctl时fd存放的地方！

631 struct file *file;

632 struct eventpoll *ep;

633

634 DNPRINTK(3, (KERN_INFO "[%p] eventpoll: sys_epoll_wait(%d, %p, %d, %d)\n",

635 current, epfd, events, maxevents, timeout));

636

637 /* The maximum number of event must be greater than zero */