对内核线程与用户态线程的影响

9.1一句话：执行上下文变成了"线程"

非 RT 内核里，CPU 上的时间被三类东西瓜分：硬中断、软中断、任务。前两者不归调度器管，优先级事实上高于任何任务——哪怕是 SCHED_FIFO 99。

PREEMPT_RT 把绝大部分硬中断处理和全部软中断处理都塞进了内核线程（第 5 章、第 6 章），把 RCU 回调、printk 输出、非 HARD 的 irq_work 也挪进了线程（第 7 章）。结果是：

9.2RT 内核上的线程清单

在 RT 内核上跑 ps -eLo pid,cls,rtprio,ni,psr,comm，能看到一批非 RT 内核没有（或不重要）的线程。下表每一项的策略和默认优先级都来自 6.12 源码，括号里是设置位置。

优先级地图

Linux 内部用一个统一的 prio 数值（越小越优先）来比较不同调度类的任务：MAX_RT_PRIO = 100 include/linux/sched/prio.h:16，RT 任务的内部 prio = 99 − rt_priority，普通任务的 prio = 120 + nice。而调度类之间则是严格分层：stop > deadline > rt > fair > idle。

9.3对内核线程的影响

持锁可被抢占，并可能被 boost

非 RT 下，内核线程拿着 spinlock_t 时是不可抢占的；RT 下这把锁是 rtmutex（第 3 章），持有者随时可能被更高优先级任务抢占。于是一个 SCHED_OTHER 的 kworker 拿着某驱动的锁被抢占，若 FIFO 80 的任务恰好也要这把锁，kworker 会被临时 boost 到 FIFO 80（第 4 章），在 ps/top 里你可能短暂看到一个 kworker 跑在 RT 优先级上——这是 PI 在工作，不是 bug。

"上下文判断"的语义变了

结论：不要用这些谓词做"保护"或"选择 GFP 标志"。需要的是显式的锁和明确的调用约定。

新的禁区：原子区里不能拿 spinlock_t

在 preempt_disable()、local_irq_disable()、raw_spin_lock() 区间里调用任何最终会取 spinlock_t 的函数——包括 kmalloc(GFP_ATOMIC)、wake_up() 的某些路径之外的大量通用 API——在 RT 下都会撞上 "sleeping function called from invalid context" kernel/sched/core.c:8671。非 RT 内核上开 CONFIG_PROVE_RAW_LOCK_NESTING 能提前查出一部分 lib/Kconfig.debug:1398。

所有中断线程默认同为 FIFO 50

这是一个刻意"中立"的默认：内核不知道网卡、磁盘、串口、CAN 控制器哪个对你的应用更重要。后果是：

• 所有中断线程之间按 FIFO 规则"先来先跑、跑完再让"，一个处理大量网络包的 irq/NN-eth0 可以连续占 CPU 很久，挡住同核的 irq/MM-can0。
• 你的关键中断（如运动控制的 CAN、编码器 GPIO）应该用 chrt -f -p 9x <pid> 抬上去；不重要的大流量中断可以压下去或绑到别的核。
• irq 线程会跟随中断亲和性迁移：irq_thread_check_affinity() kernel/irq/manage.c:1061 在线程每次被唤醒时检查 /proc/irq/N/smp_affinity 的变化并调整自己的 cpumask，所以改中断亲和性就同时改了线程跑在哪。

软中断"跟着 raise 它的线程走"

RT 下软中断由 local_bh_enable() 在当前任务上下文执行（第 6 章）。强制线程化的 handler 由 irq_forced_thread_fn() kernel/irq/manage.c:1191 包上一对 local_bh_disable()/local_bh_enable()，于是网卡 handler 里 raise 的 NET_RX_SOFTIRQ 会在 irq/NN-eth0 线程、以 FIFO 50 的优先级执行。这意味着：

• 网络协议栈的耗时被算到了网卡中断线程头上——top 里你会看到 irq/NN-eth0 很忙，而 ksoftirqd 相对清闲。
• 给网卡中断线程调优先级，等于同时调了网络软中断的优先级。

9.4对用户态线程的影响

好处与危险：用户 RT 线程现在能抢占中断处理

系统调用几乎全程可抢占

用户线程进入内核（svc → el0_svc），在 RT 下这段内核路径里的 spinlock_t 都是可睡眠的 rtmutex：

• 对高优先级线程：它在系统调用里也可以随时抢占低优先级任务——哪怕低优先级任务正拿着某把内核 spinlock。最坏延迟从"最长不可抢占区"缩短到"最长 raw 区 + PI 传递时间"。
• 对它自己：它在内核里等锁时是睡眠的，持锁者被 boost 到它的优先级。所以一个 FIFO 90 的线程调 write() 到一个被低优先级任务争用的文件系统路径，会把那个任务临时拉到 FIFO 90。
• 代价：争用时多了上下文切换，系统调用吞吐下降；sched_switch 事件数量明显上升。

定时睡眠：hrtimer 自动走 HARD

周期性 RT 线程最常用的是 clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, …)。RT 下 hrtimer 默认被挪到软中断（第 6 章）——如果唤醒 RT 线程的定时器也被挪到 SCHED_OTHER 的 ksoftirqd 里，那 RT 内核反而更差。__hrtimer_init_sleeper() 专门处理了这件事 kernel/time/hrtimer.c:2041：

if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
	if (rt_or_dl_task_policy(current) && !(mode & HRTIMER_MODE_SOFT))
		mode |= HRTIMER_MODE_HARD;
}

只有 调用时已经是 RT/DL 策略 的线程才拿到 HARD 定时器。注释里解释了为什么不对所有人开放：非特权用户可以造大量线程在同一时刻到期，在硬中断里一次唤醒成千上万个线程本身就是延迟尖峰。推论：先 sched_setscheduler，再进入睡眠循环——顺序反了，第一次睡眠可能走 soft 路径。

这条路径就是 cyclictest 和 rtla timerlat 测量的东西：从 hrtimer 到期时刻到线程真正运行的间隔。整条路径上只有硬中断那几帧是不可抢占的，其余都由优先级决定——这就是 RT 内核上 cyclictest 最大值能做到几十微秒量级的原因。

内存：缺页是 RT 线程的天敌

RT 内核让内核路径可抢占，但不会让缺页变快：一次 major fault 要读盘，minor fault 也要走 mm 的锁和页分配器（RT 下这些都是可睡眠锁，见 第 7 章）。所以 RT 应用的固定套路是：

• mlockall(MCL_CURRENT | MCL_FUTURE)：锁住所有现有和将来的映射，防止被换出；
• 预触页：在进入实时循环之前，把栈（如 memset 一个大的局部数组）和堆（预分配并逐页写一遍）都摸一遍，把 minor fault 全部提前触发；
• 实时循环里不调 malloc/free、不打开文件、不创建线程。

锁：必须用 PI mutex

用户态线程之间共享数据用 pthread_mutex，默认协议是 PTHREAD_PRIO_NONE——没有优先级继承，经典的三任务反转会原样出现。设成 PTHREAD_PRIO_INHERIT 后，glibc 走 FUTEX_LOCK_PI，内核用和 spinlock 相同的 rtmutex 做 PI（第 4 章）。条件变量配 PI mutex 时，glibc 会使用 requeue-PI。注意：sem_t、pthread_rwlock 的读锁、pthread_spinlock 都没有 PI。

普通 SCHED_OTHER 进程

• 吞吐下降：更多的抢占、更多的上下文切换、锁争用时睡眠而非自旋（虽然 rtmutex 有自适应自旋缓解）。CPU 密集的批处理任务可能慢几个百分点到十几个百分点，网络/存储密集型负载受影响更大。
• 6.12 里没有 PREEMPT_LAZY：RT 内核对 SCHED_OTHER 任务也是"立刻抢占"，不会推迟到 tick 边界。lazy preemption 是 6.13 之后用来挽回这部分吞吐的。
• 与 RT 任务共享 CPU 时，普通进程靠 RT throttling 和 fair_server 才能保证每秒拿到最低限度的 CPU。

9.5端到端：用户 RT 线程等设备数据

一个典型场景：用户态控制线程（FIFO 80）阻塞在 read() 上等一个 SPI/GPIO 设备的数据就绪中断。RT 内核上从中断到用户代码运行的完整链路：

sequenceDiagram
  autonumber
  participant Dev as 设备
  participant GIC as GICv3
  participant CPU as CPU 硬中断上下文
  participant IT as irq/N-dev 线程 FIFO 50+
  participant App as 用户线程 FIFO 80
  App->>App: read() 进入内核，wait_event_interruptible 睡眠
  Dev->>GIC: 拉高 SPI
  GIC->>CPU: 判优，投递到目标 CPU，进入 el1h_64_irq 或 el0t_64_irq
  CPU->>CPU: gic_handle_irq 读 ICC_IAR1_EL1，handle_fasteoi_irq
  CPU->>GIC: ONESHOT 先 mask 该 SPI，再 EOI
  CPU->>IT: irq_default_primary_handler 返回 IRQ_WAKE_THREAD，唤醒线程
  CPU->>CPU: 中断返回，抢占点检查 need_resched
  IT->>IT: irq_forced_thread_fn 调用驱动 handler，读设备、填缓冲
  IT->>App: wake_up_interruptible，try_to_wake_up
  Note over IT,App: App 优先级更高，同核则立刻抢占 IT
  App->>App: 从 wait_event 返回，copy_to_user，ERET 回 EL0
  IT->>GIC: 线程处理完毕，irq_finalize_oneshot 解除 mask

这张图里最值得琢磨的是最后两步的顺序。用户线程 FIFO 80 高于中断线程，所以一旦被唤醒，同核上它立刻抢走 CPU，中断线程的收尾工作——包括 irq_finalize_oneshot() 解除屏蔽——要等用户线程下一次睡眠才继续。在这段时间里该中断线保持 masked，设备的下一个中断会被 GIC 挂起（pending）而不是丢失。对周期性设备这通常无害，但如果你的用户线程处理一次数据要很久，就要考虑把中断线程优先级抬到用户线程之上，或者把两者放在不同核上。

9.6标准用户态 RT 程序骨架

下面是一份在 RT 内核上写周期性实时线程的最小骨架。每一步都对应前面章节的一个内核机制，注释里标出了原因。

#define _GNU_SOURCE
#include <pthread.h>
#include <sched.h>
#include <string.h>
#include <sys/mman.h>
#include <time.h>

#define PERIOD_NS   1000000L      /* 1 ms 周期 */
#define PRE_STACK   (256 * 1024)  /* 预触栈大小 */

static pthread_mutex_t shared_lock;

static void prefault_stack(void)
{
	volatile unsigned char buf[PRE_STACK];
	memset((void *)buf, 0, sizeof(buf));     /* ① 把栈页全部摸一遍 */
}

static void *rt_thread(void *arg)
{
	struct timespec next;

	prefault_stack();
	clock_gettime(CLOCK_MONOTONIC, &next);
	for (;;) {
		next.tv_nsec += PERIOD_NS;
		if (next.tv_nsec >= 1000000000L) {
			next.tv_nsec -= 1000000000L;
			next.tv_sec++;
		}
		/* ② 绝对时间睡眠：没有累积漂移；RT/DL 任务自动用 HARD hrtimer */
		clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &next, NULL);

		pthread_mutex_lock(&shared_lock);   /* ③ PI mutex → FUTEX_LOCK_PI */
		/* ... 本周期的控制计算，不分配内存、不做阻塞 IO ... */
		pthread_mutex_unlock(&shared_lock);
	}
	return NULL;
}

int main(void)
{
	pthread_mutexattr_t ma;
	pthread_attr_t attr;
	struct sched_param sp = { .sched_priority = 80 };
	cpu_set_t cpus;
	pthread_t tid;

	/* ④ 锁住全部内存，之后的映射也锁住：杜绝换出与大部分缺页 */
	if (mlockall(MCL_CURRENT | MCL_FUTURE))
		return 1;

	/* ⑤ 互斥量使用优先级继承协议 */
	pthread_mutexattr_init(&ma);
	pthread_mutexattr_setprotocol(&ma, PTHREAD_PRIO_INHERIT);
	pthread_mutex_init(&shared_lock, &ma);

	/* ⑥ 线程属性：显式调度策略 + 优先级（不继承创建者） */
	pthread_attr_init(&attr);
	pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
	pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
	pthread_attr_setschedparam(&attr, &sp);

	/* ⑦ 绑到隔离核（例如 isolcpus/nohz_full 里的 CPU 3） */
	CPU_ZERO(&cpus);
	CPU_SET(3, &cpus);
	pthread_attr_setaffinity_np(&attr, sizeof(cpus), &cpus);

	if (pthread_create(&tid, &attr, rt_thread, NULL))
		return 1;      /* 常见原因：没有 CAP_SYS_NICE / RLIMIT_RTPRIO */
	pthread_join(tid, NULL);
	return 0;
}

9.7线程行为对照总表

9.8小结

• RT 把"上下文等级"换成了"线程优先级"：irq/N 在 50，RCU 和 irq_work 在 1，ksoftirqd 和 printk 在普通优先级，migration/N 在 stop 类。
• 内核线程：持锁可被抢占、会被 boost；in_atomic() 等谓词不再可靠；原子区内不能碰 spinlock_t；软中断随 raise 它的线程执行。
• 用户线程：真正能压过中断处理，但必须按"依赖链在上"设计优先级；RT/DL 任务的定时睡眠自动走 HARD hrtimer；必须 mlockall + 预触页 + PI mutex + 绑核。
• 系统层面要接受吞吐下降，并处理 RT throttling / fair_server 这类"救命但会打断你"的机制——下一章讲怎么配。