Linux内核分析：poll与epoll的效率差异

"本文将探讨Linux系统中的两种I/O多路复用技术——poll和epoll，特别是在大量文件描述符(fd)情况下，epoll为何具有更高的效率。我们将通过分析内核源码来理解其工作原理和差异。" 在Linux系统中，poll和epoll是用于处理多个文件描述符的I/O事件监控机制，常用于高并发的网络服务。它们允许程序在一个或多个I/O事件准备好时得到通知，而不是阻塞等待单个事件的发生。 首先，让我们来看poll的工作原理。poll系统调用接收一个包含文件描述符的数组和超时时间作为参数。在内核2.6.9版本中，这个调用在`fs/select.c`中的`sys_poll`函数中实现。内核会检查用户提供的文件描述符数量是否超出限制，然后根据超时时间进行转换处理，以防止溢出或负值。接着，它会初始化一个名为table的`poll_wqueues`结构体，这是poll操作的关键数据结构。 `poll_initwait`初始化的`struct poll_table`包含一个函数指针，用于与各个文件系统交互，查询文件描述符的状态。当调用`poll`时，内核会遍历所有文件描述符，对每个描述符调用对应的函数，检查其是否就绪。如果没有任何描述符就绪，内核会挂起进程，直到有事件发生或超时。 然而，当文件描述符数量很大时，poll的效率会下降，因为它需要对每个描述符进行轮询。这就是epoll的优势所在。epoll使用“事件驱动”的方式，通过`epoll_ctl`添加、删除和修改文件描述符到epoll集合中，然后通过`epoll_wait`等待事件的发生。当事件发生时，内核会记录这些事件，并在`epoll_wait`返回时告知用户进程。 epoll的核心是`epoll_ctl`和`epoll_wait`。`epoll_ctl`将文件描述符注册到epoll实例，可以设置监听的事件类型（如读、写等）。`epoll_wait`则会阻塞，直到有注册的文件描述符上有事件发生。内核使用红黑树存储这些描述符，当事件发生时，仅需更新相关节点，避免了遍历整个文件描述符列表的开销。 此外，epoll还支持边缘触发（ET）模式，这种模式下，只有在文件描述符状态从非就绪变为就绪时才触发事件，避免了不必要的唤醒。而在水平触发（LT）模式下，只要文件描述符保持就绪状态，每次`epoll_wait`都会返回该事件，这在某些场景下更方便，但可能增加系统调用的次数。 总结来说，poll和epoll的主要区别在于，poll采用轮询检查的方式，适合小规模的文件描述符，而epoll利用内核数据结构优化，结合事件驱动和高效的通知机制，更适合处理大规模的并发连接。在处理大量并发连接时，epoll的性能通常优于poll。