01 · 抢占模型：不可抢占区的消失

结论：非 RT 内核里，任何持有 spinlock_t、处理 softirq、关中断的代码段都是「不可抢占区」，高优先级任务醒来后必须等它们结束；PREEMPT_NONE/VOLUNTARY 更进一步，连 preempt_enable() 和中断返回都不调度。PREEMPT_RT 把这些区域绝大部分改成可抢占，只留下 raw_spinlock_t、hardirq 桩和显式 preempt_disable() 三类极短区域。代价：抢占更频繁、上下文切换更多，且 6.12 还没有 PREEMPT_LAZY 来缓解普通任务的过度抢占。

第一层：一颗 CPU 上的时间线

先看结论：非 RT 的调度延迟由「最长不可抢占区」决定；RT 把它压缩到 hardirq 桩 + raw 区的长度。

非 RT任务 B 醒来后被 spin_lock 临界区 + softirq 挡住

同一场景 · 换成 PREEMPT_RT 内核

PREEMPT_RThardirq 桩一结束就切换到任务 B

左图是 CONFIG_PREEMPT（低延迟桌面）内核：任务 A 在系统调用里拿了一把 spinlock_t，此时网卡中断唤醒了 SCHED_FIFO 的任务 B。虽然 NEED_RESCHED 已经置位，但 preempt_count 非零，调度只能等 A 释放锁、softirq 跑完、preempt_enable() 把计数减到零之后才发生。驱动里一段几百 µs 的临界区，就是几百 µs 的抖动。

右图是同一场景在 RT 内核上：spin_lock() 不再增加 preempt_count（include/linux/preempt.h:157-162 把 PREEMPT_LOCK_OFFSET 定义为 0），hardirq 处理函数只做唤醒，中断返回时 arm64_preempt_schedule_irq()（arch/arm64/kernel/entry-common.c:270）发现 64 位 preempt_count 为零（计数为零且需要调度）立即调度。A 的临界区被切开，等 B 跑完再继续——这之所以安全，是因为 RT 下 spinlock_t 是可睡眠的 rt_mutex（第 02 章）。

第二层：preempt_count 的来源与抢占点

先看结论：RT 没有改 preempt_count 的结构，改的是「谁往里加计数」——spinlock、bh、RCU 读区三大来源都换成了不计数的机制。

非 RT谁把 preempt_count 加上去，内核在哪里才检查 NEED_RESCHED

同一场景 · 换成 PREEMPT_RT 内核

PREEMPT_RT主要来源被 migrate_disable / 睡眠锁 / 线程化替换

preempt_count 的布局（两种内核相同）

include/linux/preempt.h:27-55 定义了 32 位计数的分段：PREEMPT [0..7]、SOFTIRQ [8..15]、HARDIRQ [16..19]、NMI [20..23]。arm64 把 need_resched 放在计数之外的高 32 位：arch/arm64/include/asm/thread_info.h:29-40 是一个 union { u64 preempt_count; struct { u32 count; u32 need_resched; } preempt; }，arch/arm64/include/asm/preempt.h:8 定义 PREEMPT_NEED_RESCHED = BIT(32)，极性反转——need_resched == 0 表示需要调度（:32, :37, :42）。好处是「可抢占且需要调度」变成一次 64 位比零（:79-80 should_resched()）；代价是 arm64 的计数 RMW 不是原子的（:45-57 用 READ_ONCE/WRITE_ONCE），__preempt_count_dec_and_test() 要在 :74 重读整个 u64 以防中断在两半操作之间清了 need_resched。x86 则把 NEED_RESCHED 反向塞在同一个 32 位字的 bit 31。SOFTIRQ_DISABLE_OFFSET = 2 * SOFTIRQ_OFFSET（:55）：bit 8 表示「正在跑 softirq」，bit 9 表示「bh 已关闭」。

非 RT：三种模型的抢占点

kernel/Kconfig.preempt:14-16 里 choice 的默认值仍是 PREEMPT_NONE；发行版内核普遍打开 PREEMPT_DYNAMIC（:96-101），用 preempt=none|voluntary|full 启动参数在三者间切换——注意它 depends on !PREEMPT_RT，所以 RT 与 DYNAMIC 互斥，一个内核镜像不可能既是发行版通用内核又是 RT 内核。

RT：计数来源被替换成什么

RT 引入了两个新的 per-task 计数来承接这些语义：task->migration_disabled（include/linux/sched.h:888-890，16 位）和 task->softirq_disable_cnt（:1225-1227）。in_task() 与 softirq_count() 在 RT 下的定义也随之改变（include/linux/preempt.h:110-133）。

RT 对调度器本身的调整

ARM64 的中断返回抢占路径

arm64 没有选 GENERIC_ENTRY，arch/arm64/kernel/entry-common.c 自己实现了入口/出口；__exit_to_kernel_mode() 的注释（:70）明说它只做 trace/lockdep/RCU，「preemption handled elsewhere」。真正的抢占点是 arm64_preempt_schedule_irq()（:270-302），它按顺序做四件事：

1. need_irq_preemption()（:262-267）：PREEMPT_DYNAMIC 下是静态键 sk_dynamic_irqentry_exit_cond_resched，RT 下退化为 IS_ENABLED(CONFIG_PREEMPTION)，编译期恒真。
2. READ_ONCE(current_thread_info()->preempt_count) != 0 就返回（:280-281）——一次 64 位比较同时判断「计数为零」和「需要调度」。
3. 伪 NMI 例外（:284-290）：if (system_uses_irq_prio_masking() && read_sysreg(daif)) return;——开启 irqchip.gicv3_pseudo_nmi=1 后，从伪 NMI 返回时不做抢占；el1_interrupt() 也把 !interrupts_enabled(regs) 的情况分流到 __el1_pnmi()（:637-640），那条路径根本不调用抢占函数。
4. system_capabilities_finalized() 之前不抢占（:294-301）：早期启动与 secondary CPU 上线期间存在一个不可抢占窗口。

另两处 arm64 特有的不可抢占区：调试异常上下文显式 preempt_disable()（:445-462）；arch/arm64/Kconfig:58-83 的 ARCH_INLINE_*_LOCK if !PREEMPTION——RT 下锁操作全部走 out-of-line 函数，比非抢占 arm64 内核多一次调用开销。

ARM64 的入口开销：KPTI 与 Spectre 缓解

抢占点在异常入口/出口上，所以入口本身的开销直接进「唤醒→运行」延迟：

• KPTI（CONFIG_UNMAP_KERNEL_AT_EL0，arch/arm64/Kconfig:1696）只对 kpti_safe_list（arch/arm64/kernel/cpufeature.c:1737，含 Cortex-A35/A53/A55/A57/A72/A73、Carmel、Kryo 2xx/3xx/4xx Silver）之外且 CSV3 == 0 的核开启（典型是 Cortex-A75）；A76 及之后的核 CSV3 == 1，自动关闭。开启时每次 syscall/中断多一次页表切换与 TLB 失效，约几百 ns。kpti=（:1982；kernel-parameters.txt:2657）可强制。
• Spectre-BHB（arch/arm64/kernel/proton-pack.c:829-1034；CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY arch/arm64/Kconfig:1708）：A72/A73/A75/A76/A77/A78/A78AE/X1 等在异常入口执行分支历史清除循环，每次入口多几十 ns。nospectre_bhb（kernel-parameters.txt:4108）、nospectre_v2（:4116；proton-pack.c:90）、ssbd=（:413）、总开关 mitigations=（kernel/cpu.c:3230；kernel-parameters.txt:3515）可关闭——功能安全平台关闭前需过安全评审。
• PAC/BTI（arch/arm64/Kconfig:2005, 2115）开销可忽略；MTE（:2178）同步模式对内存访问有可见开销，RT 生产内核通常不开；SVE（:2249）状态会增加使用它的线程的切换成本（arch/arm64/kernel/fpsimd.c:1565 fpsimd_thread_switch()），无 SVE 用户时 arm64.nosve（kernel-parameters.txt:461）。

性能影响

净影响：最坏延迟下降约两个数量级；抢占更频繁、切换更多，吞吐型负载损失 0–35%。

源码定位

调优要点

• arm64 上若为 perf/硬死锁检测打开了 irqchip.gicv3_pseudo_nmi=1，记住伪 NMI 返回不抢占、local_irq_disable() 变成 ICC_PMR_EL1 写 + 同步（第 03 章）；生产 RT 系统按需开启。
• 想验证抢占点是否生效：trace-cmd record -p preemptirqsoff 或 /sys/kernel/tracing/tracing_max_latency，RT 内核上最长关抢占区应在 10 µs 量级。
• sysctl kernel.sched_rt_runtime_us=-1，否则默认 95% 限流会让长跑的 SCHED_FIFO 线程每秒停 50 ms。
• 6.12 上普通吞吐型任务与 RT 任务混跑时，抢占过于激进的问题只能靠 CPU 分区缓解（第 12 章）；如果需要 PREEMPT_LAZY，考虑 6.13+。

小结

• 不可抢占区从「持锁 / softirq / 关中断」三大类缩到「raw 锁 / hardirq 桩 / 显式关抢占」三小类，这是全文所有差异的根。
• PREEMPT_LOCK_OFFSET = 0、softirq_count() 改读任务字段、migrate_disable 计数——三处改动让抢占几乎处处可发生。
• 6.12 没有 PREEMPT_LAZY，普通任务也会被激进抢占；RT 限流默认 95% 仍在。
• 承上启下：抢占能处处发生的前提是「持锁可以睡」——这正是下一章 spinlock_t → rt_mutex 的由来。