Linux 内核里的睡眠函数粗看就是 *delay、*sleep 两大派一派忙等一派让出 CPU。名字很像脾气完全不同。udelay、ndelay、mdelay 是忙等待代码在原地空转不依赖调度器msleep、usleep_range、ssleep、schedule_timeout 是睡眠等待会把当前任务挂起等定时器到期或条件满足再被唤醒。写驱动的时候选错一个函数轻则延迟不准重则中断上下文里直接报 BUG: scheduling while atomic现场卡死。尤其是从单片机转过来的兄弟习惯了 delay() 一把梭到了 Linux 内核里必须把上下文、时长、精度、功耗分开看。这篇就按我平时调 I2C、SPI、传感器和内核线程的经验把这两类函数拆到源码层面再给一个能编译能跑的内核模块实测最后把选型表和踩坑记录摊开讲。适合正在写字符设备、平台驱动、内核线程或者准备内核面试的读者。1. 先把边界划清delay 和 sleep 不是一类东西1.1 忙等待的代价与原子上下文的刚需udelay、ndelay、mdelay这一组函数的内核实现思路很朴素算出一段循环需要执行多少次然后让 CPU 在这里数数。它不会调用schedule()不会把当前任务挂起也不会让出 CPU。好处是确定性极强在中断处理函数、软中断、tasklet、持有自旋锁的临界区里都能用。短板也很明显CPU 被白白烧掉功耗上去了同一核上的其他任务被延迟实时性受影响。你如果在中断里写mdelay(1000)那就是让 CPU 原地空转一秒别的活基本别想干。原子上下文是理解 delay 系列的关键。所谓原子上下文常见就这几类硬中断处理函数、软中断、tasklet、持有spinlock_t的代码、RCU 读侧临界区、显式调用了preempt_disable()的代码。这些位置不能睡眠因为睡眠意味着主动触发调度而调度器不能在抢占被禁止、中断上下文没有任务结构可挂起的状态下工作。所以在这种环境里短时间等一等只能用udelay或ndelay几毫秒的极端情况才考虑mdelay而且必须尽量短。我个人的习惯是中断里能不等就不等。硬件需要几十微秒的复位脉冲用udelay可以硬件需要几毫秒稳定时间最好改成下半部、工作队列或线程化中断。实在不行再考虑mdelay但参数要反复确认。mdelay本质上是循环调用udelay(1000)大参数下会明显拉高系统负载所以在实际产品代码里看到mdelay(100)、mdelay(500)我都会先怀疑这里是不是设计有问题。1.2 睡眠延时的前提进程上下文和可调度状态msleep、usleep_range、ssleep、schedule_timeout这些函数要睡眠就必须满足一个前提当前处于可调度的进程上下文。进程上下文有明确的task_struct可以设置TASK_INTERRUPTIBLE或TASK_UNINTERRUPTIBLE可以挂到定时器上然后调用schedule()让出 CPU。定时器到期后唤醒路径把任务重新放回运行队列等调度器再次选中它函数才继续往下走。所以在这些地方不能调用睡眠函数硬中断、软中断、tasklet、持有自旋锁的代码、禁用抢占的代码、RCU 读侧临界区。内核提供might_sleep()做检查打开CONFIG_DEBUG_ATOMIC_SLEEP后错误调用通常会打印BUG: scheduling while atomic或BUG: sleeping function called from invalid context后面跟一长串调用栈。这个栈非常有用别只看第一行要顺着栈找到是哪个驱动、哪个函数触发的。持有mutex时通常可以睡眠因为 mutex 本身就是可睡眠锁但也要注意锁的持有时间。你拿着一个全局 mutex 去msleep(1000)其他等锁的任务全被拖住并发性能会很难看。更好的做法是缩小锁范围先释放锁再睡眠醒来后重新检查条件。驱动里常见的模式是“加锁取状态、解锁、睡眠、重新加锁检查”这种写法比一把锁睡到底要稳得多。1.3 一张表看懂常用函数函数单位是否睡眠典型可用上下文常见场景ndelay(n)纳秒否原子/进程极短硬件时序udelay(n)微秒否原子/进程复位脉冲、寄存器等待mdelay(n)毫秒否原子/进程慎用几毫秒忙等usleep_range(min,max)微秒是进程上下文微秒到几十毫秒等待msleep(n)毫秒是进程上下文几十毫秒以上等待msleep_interruptible(n)毫秒是进程上下文可被信号打断的等待ssleep(n)秒是进程上下文秒级延时schedule_timeout(j)jiffies是进程上下文自定义等待、等待队列底座fsleep(us)微秒视长度而定进程上下文统一接口自动选择提示这张表只解决“能不能用”的问题实际选型还要看延迟长度、精度要求、是否可被信号打断、是否持锁。尤其是mdelay能不用就不用。2. 源码与实现每个函数到底怎么“等”2.1 udelay/ndelay/mdelay 与 loops_per_jiffyudelay的实现依赖一个校准值loops_per_jiffy。内核启动时会调用calibrate_delay()测出 CPU 在一个 jiffy 时间里能执行多少次空循环。jiffy 是内核时钟节拍HZ配置决定一秒钟有多少个 jiffy。比如HZ1000一个 jiffy 就是 1msHZ250一个 jiffy 是 4ms。校准完成后__udelay()根据loops_per_jiffy和要延迟的微秒数算出循环次数然后执行忙等。ndelay面向纳秒但实际精度受 CPU 频率、流水线、编译器优化、缓存状态影响。你写ndelay(50)并不保证精确 50ns。对绝大多数驱动来说几十纳秒的时序要求不应该靠软件延时硬扛应该交给硬件控制器或 SPI/I2C 时钟分频去保证。mdelay更直接在通用实现里往往是循环调用udelay(1000)所以mdelay(10)就是忙等 10ms。参数过大时有些架构还会遇到溢出或精度问题因此我通常把mdelay限制在几毫秒以内。udelay还有一个容易忽略的点它适合短延迟。Linux 设备驱动类资料里常见建议是udelay不要超过 1000 微秒超过 1ms 的忙等应该重新评估。这个建议不是死规矩而是经验边界。因为一旦超过毫秒级CPU 占用和调度延迟就会变得明显。你在probe里写udelay(5000)等于让 CPU 空转 5ms系统启动时间会被拉长如果在中断里写影响更大。2.2 msleep、msleep_interruptible、ssleep 和 jiffies 精度msleep的实现很短核心是schedule_timeout_uninterruptible(msecs_to_jiffies(msecs) 1)。这里有两个关键点。第一它把毫秒通过msecs_to_jiffies()转成 jiffies而 jiffies 的粒度由HZ决定。第二它加了一个 jiffy目的是保证至少睡够请求的时间避免在节拍边界上提前返回。结果就是msleep(1)经常不是 1ms。举个具体账HZ1000时一个 jiffy 是 1msmsecs_to_jiffies(1)得到 1再加 1等于睡 2 个 jiffy实际约 2ms。HZ250时一个 jiffy 是 4msmsecs_to_jiffies(1)向上取整为 1再加 1等于 2 个 jiffy实际约 8ms。HZ100时一个 jiffy 是 10msmsecs_to_jiffies(1)得到 1再加 1实际约 20ms。所以如果你在HZ100的系统里写msleep(1)以为只睡 1ms实测可能差出二十倍。这个坑我在早期调传感器上电时序时踩过后面凡是对毫秒以下精度有要求的场景我都不会再优先用msleep。msleep_interruptible会把任务状态设成TASK_INTERRUPTIBLE信号可以打断它返回值是剩余 jiffies。如果返回 0说明睡够了如果大于 0说明被信号提前唤醒你还得处理剩余时间。驱动里如果要提供可中断等待别忽略返回值。ssleep更简单通常是msleep(seconds * 1000)的封装适合秒级等待。但要注意参数类型和溢出别把超大秒数直接乘 1000 塞进unsigned int。2.3 usleep_range 为什么是高精度场景首选usleep_range(min, max)是我在非原子上下文里最常用的微秒级延时函数。它基于高精度定时器实现核心是schedule_hrtimeout_range()。你给一个最小值和最大值内核在这个区间内选择一个合适的时间点唤醒。调度器可以把多个相近的唤醒合并减少 CPU 唤醒次数对功耗友好。相比udelay它不忙等相比msleep它的精度更高粒度不受 jiffies 限制。使用usleep_range有几个经验点。第一min和max不要设成一样。比如usleep_range(1000, 1000)看起来要求精确 1ms实际上会让定时器合并机制没有余量容易适得其反。常见做法是给 10% 到 100% 的余量比如usleep_range(1000, 2000)。第二范围不要大得离谱。你写usleep_range(1000, 100000)等于告诉内核“1ms 到 100ms 之间都行”如果业务要求 1ms 后必须访问硬件那就可能出问题。第三usleep_range仍然会睡眠不能用在原子上下文。如果内核版本较新还可以用fsleep(usecs)。它会根据微秒数自动选择udelay、usleep_range或msleep适合不想在代码里堆一堆分支的场景。不过自动选择不代表你可以不关心上下文fsleep在短延时分支里可能忙等在长延时分支里会睡眠用之前还是得确认当前能不能睡眠。2.4 schedule_timeout 和等待队列的关系schedule_timeout是很多睡眠延时函数的底座单位是 jiffies。直接调用它时调用者通常需要先设置任务状态例如set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(msecs_to_jiffies(20));schedule_timeout_interruptible()和schedule_timeout_uninterruptible()是封装版本内部会帮你设置状态。msleep用的就是不可中断版本。schedule_timeout_interruptible返回剩余 jiffies信号提前唤醒时返回值大于 0。裸用schedule_timeout有个风险丢唤醒。如果你自己写“设置状态、检查条件、调度、醒来再检查”的循环很容易在检查条件和调度之间被另一个 CPU 唤醒导致错过事件后一直睡到超时。等待队列的wait_event_interruptible_timeout、wait_event_timeout把这些细节封装好了条件检查、加队列、设置状态、调度都在锁和内存屏障保护下完成。所以等待事件时优先用等待队列或completion不要手搓schedule_timeout。3. 实测内核模块量一量真实延迟3.1 模块代码和 Makefile下面这个模块创建一个内核线程在进程上下文里分别测udelay、usleep_range、msleep的实际耗时。代码不涉及硬件编译加载后看dmesg即可。注意这些调用都在内核线程里不在中断里所以可以睡眠。#include linux/module.h #include linux/kernel.h #include linux/delay.h #include linux/kthread.h #include linux/sched.h #include linux/ktime.h static struct task_struct *demo_task; static int demo_thread(void *unused) { ktime_t start, end; s64 delta_ns; pr_info(delay_sleep_demo: thread start\n); start ktime_get(); udelay(100); end ktime_get(); delta_ns ktime_to_ns(ktime_sub(end, start)); pr_info(udelay(100) real%lld ns\n, delta_ns); start ktime_get(); usleep_range(1000, 2000); end ktime_get(); delta_ns ktime_to_ns(ktime_sub(end, start)); pr_info(usleep_range(1000,2000) real%lld ns\n, delta_ns); start ktime_get(); msleep(20); end ktime_get(); delta_ns ktime_to_ns(ktime_sub(end, start)); pr_info(msleep(20) real%lld ns\n, delta_ns); while (!kthread_should_stop()) msleep(1000); pr_info(delay_sleep_demo: thread stop\n); return 0; } static int __init delay_sleep_demo_init(void) { demo_task kthread_run(demo_thread, NULL, delay_sleep_demo); if (IS_ERR(demo_task)) { pr_err(delay_sleep_demo: kthread_run failed\n); return PTR_ERR(demo_task); } return 0; } static void __exit delay_sleep_demo_exit(void) { if (demo_task) kthread_stop(demo_task); } module_init(delay_sleep_demo_init); module_exit(delay_sleep_demo_exit); MODULE_LICENSE(GPL); MODULE_AUTHOR(demo); MODULE_DESCRIPTION(Linux kernel delay and sleep demo);Makefile 直接使用当前内核的构建目录obj-m delay_sleep_demo.o KDIR ? /lib/modules/$(shell uname -r)/build PWD : $(shell pwd) all: $(MAKE) -C $(KDIR) M$(PWD) modules clean: $(MAKE) -C $(KDIR) M$(PWD) clean3.2 编译加载与日志观察编译和加载命令如下make sudo insmod delay_sleep_demo.ko dmesg | tail -n 30 sudo rmmod delay_sleep_demo如果dmesg权限受限可以用sudo dmesg。观察输出时重点看三行real的纳秒值。udelay(100)通常会接近 100000ns但受 CPU 频率变化、虚拟化环境、中断影响可能偏大。usleep_range(1000,2000)在开启高精度定时器的系统上通常落在 1ms 到 2ms 之间不会像msleep那样被 jiffies 粒度拖得太远。msleep(20)的实际值取决于HZHZ1000时常见 21ms 到 24msHZ250时可能到 24ms 以上HZ100时可能接近 30ms。这个模块还故意让线程在while循环里每秒睡一次方便你用rmmod时触发kthread_stop。如果线程是一次性函数直接返回kthread_stop的时序要小心处理。很多新手写测试模块时线程直接退出卸载时再去kthread_stop已经结束的任务容易出问题。让它保持可停止循环是最省事的写法。3.3 结果解读udelay、usleep_range、msleep 的差距同一台机器上多跑几次你会看到udelay的偏差通常较小但它是用 CPU 时间换来的。usleep_range的偏差来自调度延迟和定时器精度系统负载高时会变大。msleep的偏差主要来自 jiffies 粒度尤其是HZ较低的内核。很多人第一次看到msleep(20)变成 24ms 或 30ms 会觉得奇怪其实就是msecs_to_jiffies()向上取整再加 1 的结果。如果你在虚拟机上测试还要注意虚拟化时钟源和宿主负载的影响。udelay在虚拟机里可能被 CPU 频率变化影响usleep_range可能因为宿主调度而抖动。嵌入式板子上则要看CONFIG_HZ、CONFIG_HIGH_RES_TIMERS、定时器时钟源。查看当前内核配置可以用grep -E CONFIG_HZ|CONFIG_HIGH_RES_TIMERS|CONFIG_DEBUG_ATOMIC_SLEEP /boot/config-$(uname -r)如果CONFIG_HIGH_RES_TIMERS没开usleep_range的精度会下降可能退回到 jiffies 级别的行为。做传感器时序时这个配置项值得提前确认。3.4 用 ftrace 和 timer 列表继续挖想确认睡眠函数到底走了哪条路径可以用ftrace看schedule_timeout、hrtimer_start_range_ns这类函数的调用图。先把 tracing 打开sudo mount -t debugfs none /sys/kernel/debug cd /sys/kernel/debug/tracing echo 0 tracing_on echo function_graph current_tracer echo schedule_timeout set_graph_function echo 1 tracing_on sudo insmod /path/to/delay_sleep_demo.ko echo 0 tracing_on cat trace/proc/timer_list可以看当前定时器状态和高精度定时器信息但输出很长建议配合grep。这些工具的价值在于当延迟不符合预期时你能判断是 jiffies 粒度问题、高精度定时器没生效还是调度延迟太大。别只靠猜ftrace和dmesg给出的调用栈比猜靠谱得多。4. 选型实战驱动、中断、线程里到底怎么选4.1 按上下文和时长选型中断上下文里只能用 delay 系列微秒级用udelay纳秒级用ndelay毫秒级尽量把逻辑挪出去。进程上下文里选择更多10 微秒以内可以用udelay虽然忙等但够确定10 微秒到 20 毫秒优先usleep_range精度和功耗平衡较好超过 20 毫秒用msleep或msleep_interruptible秒级用ssleep。等待某个条件成立而不是单纯延时应该用wait_event_interruptible_timeout、wait_event_timeout或completion。场景推荐函数理由中断里 5us 复位脉冲udelay(5)原子上下文不能睡眠中断里 2ms 等硬件挪到工作队列后用usleep_range避免忙等拖住中断probe 里等传感器上电 2msusleep_range(2000, 3000)进程上下文精度优于msleep内核线程等 500msmsleep(500)或msleep_interruptible长延时让出 CPU等用户关闭文件wait_event_interruptible条件是事件不是固定延时秒级巡检ssleep或msleep简单直接4.2 I2C/SPI/传感器上电复位案例以传感器上电为例典型时序通常有三段复位引脚拉低至少 10 微秒、拉高后等待 1 到 5 毫秒稳定、发起第一次转换后等待几十到几百毫秒出结果。复位拉低那段如果是在probe里当然可以用usleep_range但很多驱动会选udelay(10)因为时间短忙等成本可以接受而且不依赖调度。拉高后的稳定时间probe处于进程上下文用usleep_range(1000, 2000)或usleep_range(2000, 3000)比msleep(1)稳尤其当内核HZ100时msleep(1)可能变成 20ms上电时序反而被拉长。转换等待几百毫秒时如果驱动在probe里同步等待用msleep可以但会拖慢启动。更好的设计是中断方式传感器转换完成拉一个中断驱动在中断里唤醒等待队列用户进程或内核线程从wait_event_interruptible_timeout返回。这样既不忙等也不靠固定延时猜时间。I2C 和 SPI 的传输函数本身很多会睡眠所以它们也不能在原子上下文调用这一点在写中断下半部时尤其要注意。4.3 实时内核和高精度定时器的影响实时内核配置会让调度延迟更可预测睡眠函数唤醒后的响应通常更及时。但忙等就是忙等udelay和mdelay在实时内核里照样占着 CPU不会自动让出。高精度定时器开启后usleep_range的精度会明显提升msleep仍然受 jiffies 影响因为它的底座是schedule_timeout_uninterruptible。所以在实时项目里我优先确认CONFIG_HIGH_RES_TIMERS微秒级等待用usleep_range毫秒级以上再考虑msleep。还有一个容易误解的点实时内核里普通spinlock_t的行为可能发生变化但raw_spinlock_t仍然保持不可睡眠语义。你写驱动时不要依赖“实时内核里自旋锁可以睡眠”这种假设最好按最严格的标准写持自旋锁不睡眠、不调用可能睡眠的函数。这样代码在普通内核和实时内核上都稳。4.4 常见问题速查表现象常见原因处理思路BUG: scheduling while atomic原子上下文调用了睡眠函数改用udelay或把逻辑移到工作队列msleep(1)实际远大于 1msjiffies 粒度加 1用usleep_range或调整HZusleep_range精度差未开高精度定时器或范围太宽确认CONFIG_HIGH_RES_TIMERS收窄 range中断响应变慢中断里忙等太久缩短udelay长等待挪出中断卸载模块卡住内核线程未正确停止用kthread_should_stop配合kthread_stop信号打断等待用了msleep_interruptible检查返回值处理剩余 jiffies系统功耗偏高大量udelay/mdelay忙等非原子上下文改用usleep_range5. 高频面试题与踩坑记录5.1 面试官爱问的 delay 和 sleep 区别面试里问“delay 和 sleep 有什么区别”别只答“一个忙等一个睡眠”。更完整的回答是delay 系列不依赖调度器不会让出 CPU可以在原子上下文使用但会消耗 CPUsleep 系列依赖调度器会把任务状态改成可中断或不可中断然后调用schedule()只能在进程上下文使用。udelay适合微秒级、短时间、原子上下文msleep适合毫秒级以上、进程上下文usleep_range适合微秒到几十毫秒、非原子上下文精度比msleep高。如果面试官继续问“为什么usleep_range比msleep精度高”回答核心是底层定时器不同。msleep走 jiffies 和schedule_timeout_uninterruptible粒度受HZ限制还会加一个 jiffyusleep_range走高精度定时器schedule_hrtimeout_range可以给出最小和最大范围允许调度器合并唤醒精度和功耗都更好。再问“msleep(1)为什么不准”就把msecs_to_jiffies()向上取整、加 1、HZ100/250/1000的账算一遍面试官一般就满意了。5.2 我踩过的坑msleep(1) 不是 1ms我早期调一个温湿度传感器手册写着上电后等待 1ms 再发命令。我在probe里写了msleep(1)测试机器是HZ100的定制内核结果每次上电等待实际接近 20ms。当时没意识到 jiffies 粒度问题还以为是 I2C 时钟太慢。后来用ktime_get()打点才发现msleep(1)的真实耗时远超预期。改成usleep_range(1000, 2000)后时序稳定了启动时间也短了。另一个坑是中断里等硬件。有一次为了等一个状态位我在中断处理函数里写了usleep_range(100, 200)编译没问题运行直接报BUG: sleeping function called from invalid context。后来改成短udelay轮询状态如果超时就把后续处理丢给工作队列。这个教训很深刻中断里不要有任何侥幸心理睡眠函数一调用内核就会教你做人。5.3 比 sleep 更稳的替代wait_event、completion、工作队列固定延时只是“猜硬件需要多久”而等待事件是“硬件好了就继续”。前者容易受温度、电压、批次影响后者更稳。比如传感器数据就绪中断可以用wait_event_interruptible_timeout中断里调用wake_up_interruptible等待方设置一个超时兜底。再比如两个内核线程之间的一次性通知用completion比msleep加标志位清晰得多。completion_wait_timeout还能带超时避免死等。如果确实需要在中断之后做一段较长的等待或处理工作队列和线程化中断是常用方案。中断里只做最小动作唤醒工作队列工作队列在进程上下文里可以放心用msleep、usleep_range也可以拿 mutex。这样既保证中断响应又避免原子上下文睡眠。驱动代码里看到中断处理函数又长又带循环等待通常就是重构的信号。5.4 一些能少走弯路的个人习惯我现在写驱动时会先问自己三个问题当前代码在什么上下文要等多久等的是一个固定时间还是一个条件如果是原子上下文只考虑udelay、ndelay并且尽量短如果是进程上下文10 微秒到 20 毫秒优先usleep_range再长用msleep如果是等条件优先等待队列或completion。另外测试阶段我会打开CONFIG_DEBUG_ATOMIC_SLEEP让内核帮我抓错误调用比上线后现场死机便宜得多。还有一个小习惯调延时相关代码时用ktime_get()打点别只靠肉眼和日志时间戳。dmesg的时间戳精度有限ktime_get()的差值能直接告诉你真实延迟。把udelay、usleep_range、msleep三行实测值放在模块启动日志里换板子、换内核配置时重新跑一遍很多“玄学问题”会立刻现出原形。