Linux 内核 poll_wait 等待机制：告别轮询空转，I/O 多路复用只需一份等待队列

Linux 内核 poll_wait 等待机制：告别轮询空转，I/O 多路复用只需一份等待队列

【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux

写字符设备驱动时，最劝退的场景之一就是：用户态想知道"数据好了没"，驱动里只好忙等，应用侧也只好反复 read 试错——CPU 就这么空转掉了。Linux 内核的 poll_wait 机制正是为解决这个问题而生：配合等待队列和 I/O 多路复用，让进程"没事就睡、有事才醒"，是驱动开发中性价比极高的异步 I/O 手段。

场景：轮询到底烧掉了多少 CPU

先看一个典型的反面写法。应用每隔 5ms 去读一次设备节点，直到有数据：

/* 用户态：经典轮询，纯浪费 */ char buf[64]; for (;;) { if (read(fd, buf, sizeof(buf)) > 0) break; usleep(5000); /* 睡 5ms 再来 */ }

代价很直接：

• 响应延迟：最坏情况比事件实际到来晚 5ms，想再快就缩短间隔，CPU 占用随之线性上升。
• 频率矛盾：间隔短了烧 CPU，间隔长了卡延迟，怎么调都不舒服。
• 规模放大：一个应用这样写问题不大，同时监控几十个 fd 时，CPU 基本就废了。

而内核这边，驱动若用忙等（比如自旋循环检查标志位），代价更狠——自旋关不关中断都占着核，直接拖慢整机。

心智模型：poll_wait 只干一件事

把整套机制压缩成一句话：把"反复问"改成"挂了个闹钟"。

进程在 poll 系统调用里注册："数据来了叫我"。内核把它挂进驱动持有的等待队列，然后去睡。设备上有数据到达时，驱动敲一下队列（wake_up），进程才醒来干活。CPU 在等待期间的消耗约为零。

这里的关键角色只有三个：

角色	是谁	干什么
等待队列头wait_queue_head_t	驱动自己声明	"闹钟"的挂点，所有睡眠者挂在这上面
poll_table	内核 poll 路径构造	携带"该把谁、挂到哪、醒来后做什么"的注册表
poll_wait()	驱动在 poll 回调里调用	用注册表把当前进程挂进等待队列，仅一行

注意poll_wait()本身不做睡眠——它只是完成"挂号"。真正的睡眠发生在挂完之后、事件检查又返回"没事"的时候。

一次等待的完整旅程

把用户态到内核的路径串起来看，一次"等待数据"是这样走完的：

1. 用户态发起：应用调poll(fds, 1, 5000)，内核进入 fs/select.c 的do_sys_poll()，为这次调用构造一个poll_table（其_qproc指向pollwake()）。
2. 轮询驱动回调：内核对每个 fd 走vfs_poll()→file->f_op->poll(file, pt)，也就是你驱动里实现的那个 poll 函数。
3. 挂入等待队列：poll 回调里调poll_wait()。它内部就是转手调用pt->_qproc（即pollwake()），把当前进程的一个wait_queue_entry加到驱动的等待队列头上；随后一条smp_mb()内存屏障防止"挂队列"和"检查状态"的顺序被编译器重排——这步细节在 poll.h 核心实现 里有注释说明。
4. 检查并返回事件位：挂完之后，驱动立即检查设备状态，有事件就返回如EPOLLIN | EPOLLRDNORM，没事件就返回 0。
5. 分岔口：
   • 返回了事件位 →do_sys_poll()直接返回，应用开始读写；
   • 返回 0 → 主循环调schedule()睡眠，等被叫醒。
6. 事件发生，被唤醒：中断/工作队列里驱动置好标志位，调wake_up_interruptible(&wq)。等待队列里每个 entry 对应的pollwake()按 key 过滤，命中目标事件的进程置triggered = 1并醒来，do_sys_poll()复查后向应用报告。

注意第 6 步醒来后的路径：进程醒来不是直接拿到数据，而是重新走一遍 poll 回调复查状态。这个"醒了再查"的设计是防虚假唤醒的最后一道保险。

驱动要守好的三份"合同"

poll 机制能否正常工作，取决于驱动是否同时履行以下三条。缺任何一条，表现都是"进程永远睡死"或"误醒"：

合同	要求	违反后果
① 注册	poll 回调中、检查状态之前调poll_wait(file, &my_wq, wait)	进程没挂上队列，事件来了也无人知晓，永远超时
② 报告	按真实状态返回事件位掩码，无事件返回 0	多报：应用白跑一趟（性能损耗）；少报：数据明明到了却返回 0，进程睡死
③ 唤醒	状态从"无事件"变为"有事件"的那一刻，立即wake_up_*(&my_wq)	事件被静默吞掉，所有等待者只能等超时

一个顺序上的细节值得强调：先 poll_wait 再查状态。因为查状态和挂队列之间存在时间窗，事件完全可能在这两行代码之间发生。先挂再查，配合poll_wait()内部的smp_mb()，才能保证"查无事件"是可信的——查完确实没事件，睡下去才安全。

poll 回调最小骨架

下面这段代码就是驱动侧需要写的全部：一个等待队列头、一个 poll 回调、外加事件侧的一次唤醒。对照内核真实实现，比如 hidraw 驱动 的hidraw_poll，思路完全一致：

#include <linux/poll.h> static DECLARE_WAIT_QUEUE_HEAD(my_wq); static DEFINE_SPINLOCK(my_lock); static bool data_ready; /* 有数据可读 */ /* 数据到达处（中断/DMA 完成回调里）置位并唤醒 */ void my_event_arrived(void) { spin_lock(&my_lock); data_ready = true; spin_unlock(&my_lock); wake_up_interruptible(&my_wq); } static __poll_t mydev_poll(struct file *file, poll_table *wait) { __poll_t mask = 0; unsigned long flags; /* 合同①：先挂队列 */ poll_wait(file, &my_wq, wait); /* 合同②：再如实报告状态 */ spin_lock_irqsave(&my_lock, flags); if (data_ready) mask = EPOLLIN | EPOLLRDNORM; spin_unlock_irqrestore(&my_lock, flags); return mask; }

注册到文件操作即可：

static const struct file_operations mydev_fops = { .owner = THIS_MODULE, .poll = mydev_poll, /* .read / .write ... */ };

SCSI mpt3sas 控制器驱动 是另一个可参考的完整例子：它在 poll 回调里用自旋锁遍历适配器链表检查aen_event_read_flag，事件侧统一走wake_up_interruptible(&ctl_poll_wait)。

踩坑清单：四件事最容易翻车

坑	症状	解法
惊群	10 个进程等同一队列，一次事件全部醒来，9 个发现没数据又睡回去	消费者独占消费时用wake_up_interruptible_sync()；竞争型消费可用wake_up_interruptible_nr(&wq, 1)限制唤醒数量
竞态 / 虚假唤醒	状态标志被改、队列空转或漏醒	状态检查与置位都放进同一把锁；永远"先 poll_wait 后查状态"；依赖醒来后的复查兜底
CPU 空转	事件源高频触发，top里进程占满核	把"每次事件都 wake_up"改成批量：攒够 N 个或攒够 T 微秒再统一唤醒，驱动里常见的是攒包 + 定时器兜底
唤醒风暴	中断上下文中每收一字节就 wake_up 一次	同上，事件侧做合并；能合并的唤醒尽量合并，wake_up_*不是免费午餐

另外两个高频小错：

• poll 回调里先查状态后 poll_wait：事件恰好落在两行之间时，进程挂队列后状态已就绪却返回 0，白睡到超时。顺序必须反过来。
• 事件侧忘了 wake_up：poll 永远返回 0，应用侧表现是"每次都是超时"。调试时先确认事件路径有没有走到唤醒调用。

验证与调优：睡没睡、醒没醒

看进程睡在哪——最直接的办法是抓现场：

# 应用阻塞在 poll 时的调用栈 cat /proc/<pid>/stack # 期望看到 do_sys_poll / vfs_poll / 你的 poll 回调

看等待队列本身——内核调试配置下（开启CONFIG_WAIT_DEBUG等）可用wait_dump；通用做法是结合trace-cmd跟踪schedule与唤醒事件，确认"事件发生 → 唤醒 → 进程被调度"三者的时间差：

trace-cmd record -e sched -p poll # 复现场景后 trace-cmd report | grep -E 'sched_waking|sched_switch'

降低唤醒频率的三板斧：

1. 批量：数据攒一批再 wake_up，减少唤醒次数。
2. 定时合并：短窗口内多次事件合并成一次唤醒（驱动里典型的"中断只置标志 + 定时器/工作队列触发唤醒"模式）。
3. 只唤醒需要的：wake_up_nr/wake_up_sync按场景选择，别无脑全量唤醒。

一句话带走

• poll 回调里先poll_wait挂号，再查状态报告事件位，顺序不能反。
• 等待队列头由驱动声明，wake_up_*必须在状态变化的那一刻调用——少一次唤醒，就是应用侧一次超时。
• 事件侧尽量攒批再唤醒，唤醒是资源，不是免费的。
• 用户态配合 I/O 多路复用（poll/epoll）监控多个 fd，驱动侧每加一条等待队列，整机效率就升一档——这就是告别轮询空转的完整闭环。

【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux