Linux poll内核实现与驱动开发：从select到epoll的演进

我最早接触poll的时候，想法特别简单：往一个数组里塞上文件描述符和关注的事件，调用一次，阻塞等待，返回后逐个检查revents，然后就完事了。后来真正去读 Linux 内核源码，才发现这个看似普通的系统调用里面藏着一套相当精巧的设计——它既继承了select的教训，又为后来epoll的诞生埋下了伏笔。搞清楚poll的设计哲学和内核实现，对做嵌入式驱动、网络编程乃至理解整个 Linux IO 模型的人来说，都算得上是一堂必修课。

这篇文章我会从select的痛点讲起，逐步深入到sys_poll的调用链、file_operations->poll的驱动侧实现，再对比epoll的演进逻辑。全程结合内核源码和实际踩坑经验，尽量让你读完不仅能看懂，还能在自己的项目里少走弯路。

1. 为什么有了select还要发明poll：一个"够用但不好用"的故事

1.1 select的三大痛点

要理解poll为什么存在，得先站在select用户的视角感受一下那些年大家是怎么被折磨的。

select的核心参数是三个fd_set位图，分别表示可读、可写和异常。这个设计本身没有太大问题，问题出在三个地方：

第一，fd_set的大小有硬上限。FD_SETSIZE通常被定义成 1024，也就是说你最多只能同时监听 1024 个文件描述符。如果机器的 ulimit 允许开更多 fd，select 直接就无能为力了。当然你可以通过重新编译内核或调整宏来扩大这个值，但那是"改库改内核"级别的操作，不是每个项目都折腾得起。

第二，每次调用都全量拷贝三个位图。用户空间准备三个fd_set，select进入内核后要copy_from_user把它们搬进去；返回时又要copy_to_user把修改后的位图搬回来。监听数量越大，这份拷贝成本就越高。如果 fd 很稀疏，比如只有 fd 3 和 fd 4096 需要监听，位图依然要把一整块按 1024 对齐的区域从头到尾处理一遍，空间和时间上都浪费。

第三，内核不知道哪个 fd 有事件，只能线性扫描。select的处理逻辑是逐一检查 fd_set 里的每一位，然后调用对应文件的 poll 逻辑。这意味着复杂度是 O(n)，n 再大也只能硬着头皮扫。用户空间拿到返回结果后，还得自己再遍历一遍 fd_set 才能确定"到底是谁有事件"。

这三个痛点叠加起来，在高并发或者 fd 数量很大的场景下会非常难受。

1.2 poll的改良：用pollfd数组打破1024的上限

poll做的最核心的改变，就是把"三个位图"换成了"一个结构体数组"：

struct pollfd { int fd; short events; // 关注的事件 short revents; // 返回时实际发生的事件 };

使用poll时，你提供一个struct pollfd数组，数量完全由你自己决定，不再受 1024 的限制。events是输入参数，表示关心哪些事件；revents是输出参数，由内核在返回时填充。这个"输入输出分离"的设计非常关键，它让用户空间不用在调用前后反复清理、重置位图，只需要在返回后逐个查看revents即可。

从内核实现角度看，poll使用的是"链表 + 数组"相结合的方式来组织待监听的文件，而不是固定大小的位图，因此 fd 数量由nfds参数动态决定，前提是 nfds 不能超过进程的文件描述符上限。严格来说poll在内核里也不是一次把所有 fd 放到一个连续大数组里，而是按页分批处理，避免了分配超大连续内存的问题。

1.3 一个关键设计哲学：把"关注什么"与"发生了什么"分开

我觉得poll设计上最值得品味的一点，就是它把"用户态对未来的期望"和"内核态对现状的报告"清楚地分开了。

events是用户预先表达的意图，比如"我在等这个 socket 可读"；revents是内核在某个时刻反馈的现实，比如"其实你这个 fd 出错了"。这种分离带来一个非常重要的工程收益：同一个pollfd数组可以复用，用户程序只需在每次循环前重置revents为 0（或让内核负责写），而不需要重新构建整个监听集合。相比之下，select每次调用前都要重新FD_SET构建位图，状态管理更繁琐。

理解了这个哲学，你再去看内核实现时就会发现，其实poll的整个运行过程就是在不断回答两个问题："有没有事件？""如果没有，要不要等？"——而这两个问题的答案，就是通过events和revents的分离来承载的。

2. 内核调用链解剖：sys_poll到do_pollfd的完整路径

2.1 系统调用入口与超时参数的处理

从用户态调用poll(fds, nfds, timeout)后，内核首先进入的是fs/select.c里的SYSCALL_DEFINE3(poll, ...)。这个宏展开后的函数名实际是__x64_sys_poll（x86_64 架构下），参数分别是用户态指针ufds、描述符个数nfds、以及以毫秒为单位的超时时间timeout_msecs。

入口处有几件事要做：

• 对nfds做合法性检查，nfds超过RLIMIT_NOFILE时直接返回EINVAL。这一步比select更严格，select的最大 fd 数量被FD_SETSIZE限制，而 poll 的上限与进程资源限制绑定，逻辑上更统一。
• 把timeout_msecs转换为内核时间单位jiffies，转换入口是msecs_to_jiffies。注意，这个转换过程存在取整问题，毫秒数很小时可能被转换成 0，含义是"完全不等待、只做一次轮询"；如果 timeout 为负数，则会被转成一个很大的值，等价于无限期等待。
• 将用户态的struct pollfd数组拷贝到内核态。拷贝策略不是一次性copy_from_user全部数据，而是按页批量处理，这样在做合法性检查和后续 poll 操作时，可以逐批推进，避免申请过大的临时缓冲区。

入口函数随后调用do_sys_poll，整个核心流程就都集中在这个函数里。

2.2 do_poll两段式循环：先说"有没有"，再说"等一等"

do_sys_poll里最关键的数据结构是poll_wqueues和poll_list。poll_list是一个链表节点，每个节点里保存一个struct pollfd数组的指针和数量，因为一次监听的文件描述符可能很多，内核把它们分批挂在链路上，逐批处理。

真正的循环在do_poll函数里。这个循环大致如下：

for (;;) { for (ctl = head; ctl; ctl = ctl->next) { // 逐个调用 do_pollfd，拿到每个 fd 的 mask mask = do_pollfd(nfds, fd, table, ...); if (mask) { count++; // 记录到用户空间返回区域 } } if (count || timed_out || signal_pending(current)) break; // 如果没有事件且没有超时，则挂起睡眠 poll_schedule_timeout(wait, ...); }

这段循环的逻辑可以这样理解：先"扫一遍"看当前有没有事件；如果有，直接返回；如果没有，就把当前进程挂到所有监听 fd 的等待队列上，睡眠一段时间；醒来后再"扫一遍"。这种"扫描—睡眠—再扫描"的两段式结构，就是poll内核实现的骨架。

sigpending检查也非常关键。如果有信号到达，poll会立即醒来返回-EINTR，避免进程长时间卡住不响应信号。

2.3 do_pollfd与vfs_poll：一次宏展开背后的vfs接口

do_pollfd是真正处理单个 fd 的地方。它的核心流程可以简化为几步：

1. 根据 fd 获取对应的struct file指针，这一步通过fdget完成，并处理 fd 非法或文件被关闭的情况，此时revents |= POLLNVAL。
2. 调用vfs_poll(file, pt)，这是一层 VFS 封装，最终会调用file->f_op->poll(file, pt)。
3. 将返回的mask中用户关心的事件位写回revents。

vfs_poll其实是个非常简单的包装，但它是理解 Linux 多路复用统一模型的关键：不管是select、poll还是epoll，最终都要落到设备驱动实现的file_operations->poll上。文件系统、socket、字符设备、块设备，各自实现自己的 poll 逻辑，而多路复用系统调用只是调度这些逻辑的上层框架。

2.4 挂进等待队列：poll_wait到底做了什么

poll能实现"有事件就醒，没事件就睡"的核心机密，在于poll_wait函数。

每次do_pollfd调用里，内核都会构造一个struct poll_table_entry，里面保存了当前进程、等待队列头和回调信息，然后通过poll_wait将当前进程挂到该文件对应的等待队列上。这一步很微妙：

• poll_wait本身不会阻塞，它只是"注册"——告诉等待队列头"如果以后有事件发生，请唤醒这个进程"。
• 当设备驱动真正有数据到达，调用wake_up系列函数时，会遍历等待队列上挂的所有进程，把它们标记为可运行。
• 被唤醒的进程回到do_poll循环，再次执行扫描逻辑。

这里有一个知识点值得注意：poll之所以要把当前进程挂到每一个监听 fd 的等待队列上，而不是只挂一个，是因为内核无法预知哪个 fd 会先到达事件。挂到所有队列上，是"宁可多挂，不可漏掉"的策略。但这也带来一个问题：每次poll调用都要渲染一堆等待队列项，调用结束后又要删除它们。这个"建立—删除"的反复操作，在大规模 fd 场景下非常昂贵，也是后来epoll想解决的问题之一。

3. 驱动侧实现：file_operations->poll的写法与常见坑

3.1 返回值mask是一张"事件账单"

对驱动开发者来说，poll不是一个需要直接调用的函数，而是需要你在struct file_operations里实现的一个回调。原型是：

unsigned int (*poll)(struct file *filp, struct poll_table_struct *wait);

这个函数要做两件事：

1. 根据设备当前状态，计算返回哪些事件掩码位；
2. 如果设备暂时没有可读/可写条件，调用poll_wait把当前进程挂到对应的等待队列上。

返回值的掩码位主要有：

很多驱动新手会犯一个错误：只实现了读等待队列，忘了写等待队列，结果应用层只要缓冲区一满就永远等不到POLLOUT，发送线程直接卡死。

3.2 一个字符设备驱动的poll实现示例

假设我写了一个虚拟串口驱动，内部用kfifo做收发缓冲。驱动里定义了读等待队列read_wq和写等待队列write_wq，poll 实现大致长这样：

static unsigned int demo_poll(struct file *filp, struct poll_table_struct *wait) { struct demo_dev *dev = filp->private_data; unsigned int mask = 0; poll_wait(filp, &dev->read_wq, wait); poll_wait(filp, &dev->write_wq, wait); if (kfifo_len(&dev->recv_fifo) > 0) mask |= POLLIN | POLLRDNORM; if (kfifo_avail(&dev->send_fifo) >= MAX_PACKET_SIZE) mask |= POLLOUT | POLLWRNORM; return mask; }

当设备收到外部数据，把数据写入recv_fifo后，需要这样唤醒等待的进程：

wake_up_interruptible(&dev->read_wq);

这一步非常关键。poll本身只是把进程挂上去，没有任何机制能自动知道设备状态变化了，必须由驱动在状态变化点主动wake_up。如果你实现了poll却在数据到达时不调用wake_up，应用程序就会一直睡下去。

file_operations结构体里挂上：

static const struct file_operations demo_fops = { .owner = THIS_MODULE, .poll = demo_poll, .read = demo_read, .write = demo_write, ... };

这样用户态就能正常poll这个设备节点了。

3.3 我踩过的两个驱动poll的坑

第一个坑是漏了wake_up。有一次我写 SPI 设备驱动，poll实现完，用户态程序注册了POLLIN，结果数据明明到了，poll永远超时。排查到最后发现，中断处理函数里只把数据塞进了缓冲区，忘了加wake_up_interruptible(&dev->read_wq)。这让我意识到，poll的正确性不光取决于 poll 回调本身，更取决于设备状态变化的触发路径是否都能唤醒等待队列。

第二个坑是返回掩码的时机不对。早期实现里，我习惯在 poll 被调用时立刻检查缓冲区，却发现应用层poll返回了POLLIN，但紧接着调用read时缓冲区已经被其他线程读空，导致read阻塞。这不是 poll 的问题，而是"事件已过期"的经典竞争。解决办法是在驱动 read 实现中保证"只要有数据返回，就绝不让 read 阻塞等待新数据"——即用非阻塞语义配合 poll，数据存在时直接返回，数据不存在且O_NONBLOCK时返回-EAGAIN。

对驱动来说，一个比较重要的习惯是：poll回调应当是无副作用的、原子的、快速的。它会在进程上下文被频繁调用，不要在 poll 里做可能睡眠的锁等待或者大块内存分配，否则会拖慢整个多路复用循环。

4. 用户态使用细节：poll的边界条件和隐藏问题

4.1 最简可运行示例

随手写一个监听两个描述符的伪代码：

struct pollfd fds[2]; fds[0].fd = fd_a; fds[0].events = POLLIN; fds[0].revents = 0; fds[1].fd = fd_b; fds[1].events = POLLOUT; fds[1].revents = 0; int ret = poll(fds, 2, 5000); // 5秒超时 if (ret > 0) { if (fds[0].revents & POLLIN) { // fd_a 可读 } if (fds[1].revents & POLLOUT) { // fd_b 可写 } } else if (ret == 0) { // 超时 } else { // 出错，注意 errno }

这是再标准不过的用法。但实际工程里，事件返回后怎么处理、怎么重新注册，才是真正区分老手和新手的地方。

4.2 返回之后别急着read：二次确认与竞争窗口

poll返回某个 fd 的revents可读，并不代表你一定能读到数据。这个"不代表"有两层意思：

一是多线程共享 fd 时的竞争：另一个线程可能在你 poll 返回后抢先 read 了，你再去 read 就什么都没有，如果 fd 是阻塞模式，read 会卡住。标准做法是配合O_NONBLOCK使用非阻塞 fd，read 返回EAGAIN时重试或放弃。

二是事件含义是"此刻或未来很短一段时间内会发生"，不一定保证对端已经发送完一个完整消息。tcp socket 场景里，POLLIN只代表内核接收缓冲区中有字节，不代表有一条完整报文。你必须自行定义并解析消息边界。

实践中我的习惯是：poll返回可读后，循环调用read直到EAGAIN，把当前缓冲区尽量耗尽，再回到poll等待下一批事件。这样能减少系统调用次数，也能降低"读完一次后又立刻被 poll 唤醒"的频率。

4.3 EINTR、POLLNVAL与fd关闭的并发问题

poll出错返回 -1 时，最常见的原因是EINTR，也就是在等待过程中被信号打断。很多人会直接perror退出，但更稳妥的做法是：

do { ret = poll(fds, nfds, timeout); } while (ret < 0 && errno == EINTR);

否则一个SIGCHLD、SIGALRM就能让你的事件循环意外退出。

revents里有一类事件比较隐蔽，就是POLLNVAL。它表示 fd 没有指向一个打开的文件，也就是"fd 不合法"。这个事件不需要你在 events 里注册，内核会自动填到 revents 里。所以每次返回后，除了检查你关心的事件位，我建议顺手检查POLLNVAL | POLLERR | POLLHUP，尤其是网络编程里对端断开或 fd 被误关的场景。

还有一个多线程下的经典问题：线程 A 正在 poll fd X，线程 B 同时 close 了 fd X。这在 C 语言层面属于未定义行为，表现可能是POLLNVAL，也可能直接导致程序崩溃，因为 poll 内部获取 file 引用时可能拿到一个已经被释放的结构体。稳妥的方案是：不要在多线程里对同一个 fd 边 poll 边 close，务必保证"close 只发生在没有其他线程正在 poll 该 fd 的时候"。poll不像epoll那样可以在epoll_ctl(EPOLL_CTL_DEL)时解绑，它对 close 的并发保护非常弱。

4.4 ppoll：当信号屏蔽需要原子性时

poll还有个进阶变体ppoll，多了一个sigmask参数。它解决的问题是：经典poll在等待期间，如果收到信号会直接返回EINTR，你不得不先阻塞信号、调用 poll、再解除信号，但这两步之间存在竞争窗口。ppoll把"设置信号屏蔽集"和"等待事件"合并成一个原子操作，在信号处理场景下更安全。

由于ppoll的超时参数是struct timespec，精度也比毫秒级poll更高，所以在对实时性有一定要求但还没到必须用epoll的场景下，ppoll是一个不错的折中。

5. 从poll到epoll：为什么大并发场景换了个思路

5.1 每次全量重做的代价

poll在大并发场景下有几笔"逃不掉的成本"：

• 每次调用拷贝全量 fd 数组：无论事件有没有发生，用户态都要把struct pollfd数组传到内核，返回时还要写回revents。fd 数量越大，拷贝量越大。
• 每次调用都全量扫描：即使只有 1 个 fd 有事件，内核也要把 n 个 fd 全部走一遍do_pollfd。
• 每次调用都要重新注册等待队列：进程从睡眠到唤醒的往返过程中，需要不断把进程挂上所有等待队列、再摘除。fd 数量大时，这个"挂—摘"操作本身就是巨大的 CPU 开销。
• 唤醒时惊群效应：多个进程如果同时 poll 同一个 fd，wake_up会把所有等待者都唤醒，但真正能处理事件的只有一个，其余会再次进入睡眠。

这些成本叠加，导致poll的复杂度逼近 O(n)，连接数上万之后性能会直线下降。

5.2 epoll的语义变更：从"扫描"到"回调"

epoll的核心思路是"注册一次、反复使用"。

你通过epoll_ctl(EPOLL_CTL_ADD)将 fd 和关注事件交给内核，内核为这个 fd 维护一个长期存在的等待队列项，并在 fd 就绪时通过回调机制把该 fd 放入一个就绪链表。epoll_wait只是去查这个就绪链表里有没有东西，有就直接拷贝给用户空间，没有就睡眠。

两者的本质差异可以这样理解：poll 是"每次扫描所有 fd，问一遍你们有没有事"；epoll 是"你们有事了主动举手，我只数举手的人"。在空闲连接多的场景下，epoll 的复杂度接近 O(1)，而 poll 仍然是 O(n)。

另外 epoll 还提供EPOLLONESHOT等更细粒度的控制，帮助设计多线程事件分发模型，避免同一个 fd 被多个 worker 同时消费。

5.3 poll在当下依然不淘汰的三个场景

虽然 epoll 在高并发 web 服务里几乎成了默认选择，但 poll 并没有退出历史舞台。至少这三类场景我会继续用它：

1. 少量 fd 的简单监听：如果只监听几个 fd，poll 的代码比 epoll 简洁太多，不需要 epoll_fd、事件表管理和epoll_ctl的错误处理，心智负担小。
2. 嵌入式环境或老内核：很多嵌入式 Linux 环境的内核版本较旧，或者为了兼容性不能依赖epoll，poll 是最通用的多路复用接口。
3. 驱动与 VFS 层的接口基础：epoll 自身也依赖file_operations->poll来完成初始事件探测和等待队列注册。也就是说，驱动开发者无论如何都要把 poll 回调实现对，理解了poll的内核机制，才能真正理解 epoll 为什么快、怎么快。

从学习价值上看，我反而建议先彻底搞懂poll的内核实现，再去看epoll的源码，你会发现很多概念是相通的，只是epoll把"临时注册"变成了"长期注册"，把"扫描"优化成了"回调"。

最后再分享一个排查技巧：如果你的应用在并发高时出现"poll 明明返回了POLLIN，但 read 却EAGAIN"或者"进程卡在 poll 超时上迟迟不醒"，除了查应用逻辑，建议先用strace看一下 poll 的参数和返回值，再用cat /proc/<pid>/fdinfo/<fd>或lsof确认 fd 是否被多线程共享。很多情况下，问题不是出在 poll 本身，而是出在 fd 的生命周期管理和事件消费竞态上，这一点在写高并发服务时尤其重要。