1. 项目概述一个关于Linux内核调度的深度追问“哪些关闭了Linux抢占抢占又关闭了谁” 这个标题乍一看像是个绕口令但它精准地指向了Linux内核调度器中最核心、也最容易被误解的概念之一抢占Preemption。对于任何一个在Linux环境下进行过性能调优、驱动开发或者内核模块编写的工程师来说理解抢占的开关状态是理解系统实时性、响应延迟乃至并发安全性的基石。这不仅仅是理论它直接关系到你的程序在高负载下是否会卡顿你的中断处理程序ISR是否会因为被不恰当地打断而丢失数据或者你的自旋锁spinlock是否会引发死锁。简单来说Linux的抢占机制允许更高优先级的任务“抢占”当前正在CPU上运行的低优先级任务从而获得立即执行的权利这对于提高系统的交互性和实时响应能力至关重要。然而并非所有时刻都适合发生抢占。内核的某些关键路径critical path必须被完整、原子地执行不能被随意打断否则会导致内核数据结构不一致引发系统崩溃或数据损坏。因此内核提供了多种机制来“关闭抢占”。那么到底是谁、在什么情况下“关闭”了抢占而“抢占”这个机制本身当其被关闭时又“关闭”或“阻止”了哪些事件的发声这正是标题所蕴含的两个核心问题一是识别出内核中那些禁止抢占的“开关”如自旋锁、中断上下文、preempt_disable()等二是深入分析当抢占被禁止后对整个系统调度行为产生的具体影响如高优先级任务无法及时运行、调度延迟增加等。本文将从一个一线内核开发者的视角拆解这两个问题并分享在实际工作中排查因抢占问题引发的性能瓶颈或稳定性问题的实战经验。2. 核心概念解析什么是Linux内核抢占在深入探讨“关闭”之前我们必须先清晰地理解“抢占”本身。Linux内核的抢占模型经历了从非抢占式到可抢占式的演变这是其支持实时应用和高交互性系统的关键。2.1 从非抢占式内核到可抢占式内核早期的Linux内核2.4及之前本质上是非抢占式的。这意味着一旦一个进程或内核线程通过系统调用进入内核态执行它就会一直持有CPU直到它主动放弃比如调用schedule()主动调度、因等待资源而睡眠、或者完成系统调用返回用户态。在此期间即使有一个更高优先级的实时任务就绪它也必须等待当前内核路径执行完毕。这导致了不可预测的、可能很长的调度延迟不适合对响应时间有严格要求的实时应用。从2.6内核开始Linux引入了可抢占式内核的选项CONFIG_PREEMPT。在这个模式下即使进程处于内核态只要它不持有任何阻止抢占的锁或处于某些特定的临界区内核就可以被更高优先级的任务抢占。这极大地降低了内核态的调度延迟使得用户态的高优先级任务可以更快地获得CPU。2.2 抢占发生的时机与条件抢占并非随时随意发生。它主要在两个点上被检查从中断处理程序返回内核态时这是最常见、最重要的抢占检查点。当硬件中断处理完毕准备从中断上下文返回到被中断的内核路径时调度器会检查当前任务的need_resched标志。如果该标志被设置例如因为一个更高优先级的任务被唤醒并且当前内核路径是“可抢占的”那么就会发生抢占直接切换到高优先级任务。在特定的内核代码路径中显式调用preempt_check_resched()内核开发者会在一些较长的循环或可能耗时的内核函数中插入此检查点以增加抢占机会。关键条件能否发生抢占取决于当前上下文是否处于“可抢占状态”。这个状态由当前任务的thread_info-preempt_count计数器决定。这个计数器就像是抢占的“门禁卡”。当preempt_count为0时门禁打开抢占允许当preempt_count大于0时门禁关闭抢占禁止。3. 谁关闭了抢占—— 深入preempt_count计数器preempt_count计数器是一个32位的整数但它被精细地划分为几个字段共同决定了当前上下文的“不可抢占性”来源。理解它的构成就理解了“谁”关闭了抢占。/* * 典型划分 (架构可能略有不同): * Bits 0-7: 抢占禁用计数 (Preemption Disable Count) * Bits 8-15: 软中断禁用计数 (Softirq Disable Count) * Bits 16-23: 硬中断禁用计数 (Hard IRQ Disable Count) * Bits 24-27: 不可迁移计数 (Migration Disable Count, 用于某些场景) * Bits 28-31: 紧急/特殊用途 */3.1 显式抢占禁用preempt_disable()/preempt_enable()这是最直接的方式。内核代码通过调用preempt_disable()来增加抢占禁用计数通常是上述bit 0-7部分调用preempt_enable()来减少它。当计数0时抢占被禁止。为什么需要显式禁用主要是为了保护每CPU变量per-CPU variable或一些非线程安全的内核数据结构的短时间操作。例如DEFINE_PER_CPU(int, my_counter); void increment_counter(void) { preempt_disable(); // 关闭抢占确保我们在整个操作期间停留在同一CPU上 __this_cpu_inc(my_counter); // 操作每CPU变量 preempt_enable(); // 重新允许抢占 }注意preempt_disable/enable是嵌套的。你必须成对调用确保禁用和启用的次数匹配否则会导致抢占被永久关闭或过早开启引发难以调试的问题。在实际编码中强烈建议使用get_cpu()/put_cpu()这对宏它们包含了preempt_disable/enable语义更清晰专用于保护每CPU变量访问。3.2 中断上下文硬中断与软中断当中断发生时处理器会自动进入中断上下文。为了确保中断处理程序尤其是同一个中断的嵌套能够原子执行内核在进入中断处理顶层时会自动增加preempt_count中的硬中断计数部分。这意味着在硬中断上半部Top Half执行期间抢占始终是禁止的。这是合理的因为中断处理需要尽可能快且通常操作共享硬件资源不能被随意打断。当中断上半部完成后可能会触发软中断Softirq或任务队列tasklet。内核在处理软中断时会增加preempt_count中的软中断计数部分。同样在单个软中断执行期间抢占也是禁止的。但是软中断处理是可以被硬中断打断的这是中断上下文的嵌套规则。一个关键区别虽然中断上下文禁止了普通的内核抢占但Linux内核支持线程化中断CONFIG_IRQ_FORCED_THREADING。当启用此选项后大部分中断处理程序会作为一个内核线程运行此时它们就具备了可被抢占的属性除非它们自己调用了preempt_disable但这属于高级配置。3.3 锁机制自旋锁与读写锁这是实践中导致抢占被关闭的最常见、也最隐蔽的原因。当你获取一个自旋锁spin_lock时锁函数内部不仅会忙等待直到锁可用还会隐式地调用preempt_disable()。释放锁spin_unlock时则会调用preempt_enable()。为什么自旋锁要关闭抢占这是为了防止死锁。考虑以下场景任务A在CPU 0上持有一个自旋锁lock。任务A被高优先级任务B抢占。任务B在CPU 0上运行也试图获取同一个lock。任务B将开始忙等待自旋因为锁被任务A持有。但任务A无法继续运行来释放锁因为它被任务B抢占了。 结果就是死锁。任务B在自旋等待永远无法释放锁的任务A而任务A又因为任务B的抢占而得不到CPU。关闭抢占确保了持有自旋锁的任务在释放锁之前不会被赶下CPU从而避免了这种单CPU上的自旋锁死锁。实操心得这也是为什么在中断上下文中必须使用spin_lock_irqsave()而不是简单的spin_lock()的原因。spin_lock_irqsave不仅关闭抢占、获取锁还会保存当前中断状态并禁用本地CPU中断。这是为了防止中断处理程序可能在另一个CPU上尝试获取同一个锁导致双CPU死锁。忘记使用_irqsave或_irq变体是驱动开发中常见的死锁根源。读写锁rwlock_t的行为与自旋锁类似在获取写锁时会禁用抢占。3.4 RCU读侧临界区RCURead-Copy-Update是一种高级同步机制它对读操作极其友好。读者通过rcu_read_lock()和rcu_read_unlock()标记一个读侧临界区。在旧版本的实现或某些配置下rcu_read_lock可能会通过preempt_disable来关闭抢占以确保读者在整个临界区内停留在同一CPU上这对于RCU的垃圾回收机制是必要的。但在现代内核CONFIG_PREEMPT_RCU中为了进一步降低读侧延迟rcu_read_lock可能不再禁用抢占而是采用其他机制如计数器或状态标记来跟踪读者。不过理解RCU区域可能影响抢占状态仍然很重要尤其是在分析复杂并发代码时。3.5 其他场景关中断、内存屏障等local_irq_disable()/local_irq_save()禁用本地CPU中断。由于抢占检查发生在中断返回路径禁用中断也就隐式地延迟了抢占的发生直到中断重新启用。但这与直接操作preempt_count有所不同它阻止的是抢占检查的触发点。内存屏障Memory Barriers如barrier()它本身不改变抢占状态但因为它影响编译器优化和CPU指令重排通常被用在同步原语中与抢占控制代码协同工作。4. 抢占关闭后影响了谁—— 系统行为深度分析当抢占被上述任何一种机制关闭后系统的调度行为会发生显著变化。标题中的“抢占又关闭了谁”指的就是那些被“阻止”或“延迟”的事件和任务。4.1 对高优先级任务调度延迟的影响这是最直接的影响。假设一个低优先级的任务A在内核态执行并且持有一个自旋锁意味着抢占被禁用。此时一个高优先级的实时任务B变为就绪状态。在正常情况下调度器会立即抢占A让B运行。但由于A禁用了抢占调度器在need_resched标志被设置后无法立即强制执行上下文切换。任务B必须等待直到任务A离开临界区释放锁退出中断处理或调用preempt_enable将preempt_count降为0。在中断返回路径或下一个抢占检查点上调度器才能实际执行切换。这个等待时间就是任务B增加的调度延迟。在内核实时补丁如PREEMPT_RT中一个核心工作就是将自旋锁替换为可抢占的互斥锁并精细化中断处理就是为了最小化这种延迟。4.2 对内核代码执行流的影响抢占关闭期间当前执行流获得了对CPU的“独占”承诺在同一CPU上。这带来了两个副作用CPU独占与负载均衡调度器的负载均衡器在迁移任务时会考虑任务的抢占计数。如果一个任务禁用了抢占负载均衡器可能会避免将其迁移到其他CPU因为这可能违反其需要停留在同一CPU的假设例如它在操作每CPU变量。这可能导致某个CPU忙而其他CPU闲的不均衡状态。长延迟路径的风险如果开发者在抢占禁用区编写了耗时的代码如循环处理大量数据、进行缓慢的I/O操作就会长时间阻塞高优先级任务严重损害系统响应性。这是内核开发中的大忌。良好的实践是确保抢占禁用区内的代码尽可能短小、快速。4.3 对性能剖析和调试的影响当我们使用perf、ftrace等工具进行性能剖析或调度跟踪时抢占状态会影响我们对函数执行时间的解读。例如一个函数foo()在perf报告中显示占用了很长的CPU时间。这有两种可能foo()函数本身执行很慢。foo()函数内部或它的调用者禁用了抢占然后调用了一个很短的函数bar()但在此期间一个高优先级任务被阻塞了。perf采样到的“时间”实际上包含了foo()执行时间 高优先级任务被阻塞的等待时间但采样点都落在了foo()的上下文中。因此在分析性能热点时需要结合调度事件跟踪如trace-cmd record -e sched_switch来查看在热点函数执行期间是否发生了任务阻塞以判断是否是抢占禁用导致了延迟累积。4.4 对死锁和活锁的潜在贡献如前所述自旋锁与抢占禁用的交互是死锁的经典温床。此外还有一种更隐蔽的情况优先级反转Priority Inversion。虽然Linux内核的实时互斥锁rt_mutex实现了优先级继承Priority Inheritance来缓解此问题但在复杂的锁嵌套场景或使用原始自旋锁时如果高优先级任务因等待低优先级任务持有的锁而被阻塞而低优先级任务又因为抢占被禁用而无法被中等优先级任务抢占以尽快执行完毕释放锁就会导致高优先级任务被无限期延迟。这本质上是一种活锁。5. 实战如何诊断与抢占相关的问题遇到系统响应慢、实时任务延迟、或是诡异的“卡住”几秒又恢复的情况抢占问题往往是怀疑对象之一。以下是一些实战排查技巧。5.1 使用ftrace跟踪抢占与调度事件ftrace是内核内置的强力跟踪工具非常适合分析此类问题。# 1. 设置跟踪点 echo 1 /sys/kernel/debug/tracing/events/preempt/enable echo 1 /sys/kernel/debug/tracing/events/sched/enable # 特别关注 sched_switch任务切换和 sched_wakeup任务唤醒 echo 1 /sys/kernel/debug/tracing/events/sched/sched_switch/enable echo 1 /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable # 2. 开启跟踪 echo 1 /sys/kernel/debug/tracing/tracing_on # 3. 运行你的测试负载或重现问题 # 4. 停止跟踪并查看结果 echo 0 /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace /tmp/trace.log在trace.log中你可以搜索preempt_disable和preempt_enable事件看它们是否在预期之外的地方被频繁调用或长时间配对。更有效的是结合sched_switch如果一个高优先级任务被唤醒sched_wakeup但它的实际运行在sched_switch中显示被延迟了很长时间那么在这段延迟期间观察是哪个任务在执行并检查该任务是否处于抢占禁用状态可以通过其pid关联的preempt_disable事件判断。5.2 检查/proc/pid/stack与/proc/pid/wchan当某个任务看起来“卡住”不执行时找到卡住的任务PID使用ps、top或htop。查看内核调用栈cat /proc/PID/stack。这会显示该任务当前在内核中执行到了哪个函数。如果栈顶显示它在某个自旋锁函数如do_raw_spin_lock中或者在一个循环里这就是线索。查看等待通道cat /proc/PID/wchan。这会显示任务正在等待什么内核事件。如果显示是schedule或类似说明它可能在主动睡眠但如果显示为空或一个锁的名字可能意味着它在自旋等待。综合判断如果栈显示它在持有锁的代码路径中例如在spin_lock之后spin_unlock之前并且wchan无明确睡眠信息同时系统中有高优先级任务在就绪队列中那么很可能就是因为持有锁而禁用抢占阻塞了调度。5.3 使用trace-cmd和kernelshark进行图形化分析对于更复杂的问题trace-cmdftrace的前端和kernelsharkGUI工具的组合是神器。它们可以可视化地展示一段时间内所有CPU上的任务切换、唤醒、抢占事件让你直观地看到高优先级任务在哪里被阻塞了阻塞了多久以及当时CPU上正在运行的任务是谁。5.4 代码审查与最佳实践检查很多时候问题源于代码编写不符合内核并发编程的最佳实践检查锁的持有时间是否在锁内执行了可能睡眠的函数如kmalloc(GFP_KERNEL)、copy_from_user这会导致死锁。检查中断上下文代码在中断上半部是否试图获取可能被进程上下文持有的锁是否使用了错误的锁函数该用spin_lock_irqsave却用了spin_lock评估抢占禁用区的长度用preempt_disable/enable包裹的代码块是否尽可能短是否包含了循环或可能耗时的操作使用正确的同步原语是否该用信号量semaphore或互斥锁mutex的地方误用了自旋锁自旋锁只应用于非常短期的保护且持有锁时绝对不能睡眠。6. 常见问题与排查技巧实录以下是一些在实际开发和运维中遇到的典型场景和解决思路。6.1 场景一音频播放出现周期性“爆音”或卡顿现象在多媒体制作或低延迟音频应用场景下系统偶尔会出现音频断流或爆音使用cyclictest测试发现最大延迟Max Latency有异常尖峰。排查思路使用ftrace锁定延迟发生时刻在运行cyclictest的同时记录调度和中断事件。分析尖峰时刻的CPU状态在延迟尖峰的时间点查看是哪个任务/中断正在占用CPU。常见罪魁祸首某个内核线程或驱动任务长时间禁用抢占例如一个文件系统扫描、内存整理kswapd或某个驱动的工作队列workqueue函数持锁时间过长。中断风暴某个设备产生大量中断而中断处理程序上半部执行时间较长。由于中断上半部禁用抢占会持续阻塞用户态实时任务。不当的CPU亲和性设置将实时任务和可能产生高内核负载的后台任务如编译、备份绑定到了同一个CPU核心。解决措施对于内核线程尝试调整其优先级chrt或CPU亲和性taskset将其与实时任务隔离。对于驱动审查其中断处理程序和底半部机制确保上半部尽可能快将耗时操作推到任务队列或线程化中断中。使用cgroups的cpuset控制器或isolcpus内核参数隔离出专用的CPU核心给实时任务使用。6.2 场景二自定义内核模块导致系统“冻住”几秒后恢复现象加载一个自行开发的内核模块后系统会不定期地完全无响应鼠标键盘不动约5-10秒后自动恢复。排查技巧怀疑死锁或长时间锁持有这种“冻住”又恢复的现象很像一个任务持有了某个关键锁如一个全局的spinlock或rcu_read_lock并且在其临界区内执行了非常耗时的操作如通过vmalloc分配大块内存、或进行低速设备I/O。在此期间所有试图获取该锁的其他任务包括一些关键的内核线程都会自旋等待导致系统看似冻结。获取“冻住”时的信息如果系统支持网络控制台netconsole或串口控制台可以在“冻住”时尝试按SysRq组合键如AltSysRqt来打印所有任务的内核栈。这能直接告诉你每个CPU卡在什么地方。审查模块代码锁内耗时操作仔细检查所有spin_lock/spin_unlock、read_lock/read_unlock之间的代码。是否有循环是否有调用可能引起直接内存回收__alloc_pages_slowpath或I/O等待的函数中断处理模块的中断处理程序是否过于复杂是否错误地在中断上下文中使用了可能睡眠的函数使用动态调试在模块中关键锁操作和可能耗时的函数入口出口添加pr_debug或printk通过dynamic_debug控制输出观察“冻住”前最后的日志。实操心得对于可能耗时的操作一个黄金法则是“锁内不做事做事不加锁”。如果必须在锁保护下处理数据考虑将数据拷贝到锁外的一个临时缓冲区然后快速释放锁再在锁外处理这个缓冲区。对于内存分配在锁外用GFP_KERNEL分配好或者在锁内使用绝不会睡眠的GFP_ATOMIC或GFP_NOWAIT标志但需处理分配失败的情况。6.3 场景三多线程应用在特定CPU核心上性能急剧下降现象一个多线程应用将其线程绑定到不同的CPU核心上运行。发现绑定到CPU 0的线程性能正常但绑定到CPU 2的线程吞吐量或延迟指标差很多。排查思路检查CPU亲和性与中断使用mpstat -P ALL 1查看各CPU的中断数%irq和%soft。很可能CPU 2正在处理大量的网络或存储设备中断。中断处理禁用抢占会干扰该CPU上应用线程的运行。检查每CPU内核线程使用ps -eLo psr,pid,comm | grep -E \^( 2)\查看CPU 2上运行的所有内核线程。是否有像ksoftirqd/2、rcu_sched、watchdog/2等线程频繁运行并消耗CPU这些线程虽然可以抢占但如果它们频繁被调度也会挤占应用线程的时间片。检查调度统计信息使用perf sched命令记录和分析调度延迟。可以清晰地看到应用线程在CPU 2上是否频繁被抢占以及被谁抢占。检查NUMA效应如果系统是非一致性内存访问NUMA架构确保应用线程和它访问的内存位于同一个NUMA节点。跨节点访问内存的延迟可能很高。解决措施中断平衡使用irqbalance服务或手动设置echo mask /proc/irq/IRQ/smp_affinity将中断分散到不同的CPU避免集中到应用线程所在的核心。CPU隔离使用isolcpus内核参数将CPU 2从通用调度器中隔离出来专门用于运行应用线程。但要注意这需要手动将中断和其他内核线程也移出该核心。调整内核线程优先级对于某些非关键的内核线程可以适当降低其优先级chrt但需谨慎避免影响系统核心功能。理解“哪些关闭了Linux抢占”以及“抢占又关闭了谁”是深入Linux系统性能、实时性和稳定性调优的必经之路。它要求开发者不仅了解API的用法更要理解其背后的并发原理和系统全局视图。当你在代码中写下spin_lock或preempt_disable时心里应该清楚你不仅是在保护一段数据更是在短暂地修改整个CPU的调度规则。这种敬畏之心是写出稳健高效内核代码的开始。