Linux RT 调度器的限流机制：rt_throttled 标志的触发与解除

一、核心概念解析

1.1 RT 调度基础

Linux 实时调度包含两类策略：

• SCHED_FIFO：先进先出，无时间片，高优先级任务一旦运行，除非主动放弃或被更高优先级抢占，否则持续执行
• SCHED_RR：轮转调度，同优先级任务按时间片（默认 100ms）轮流执行，时间片用完排到队尾

实时任务优先级范围1-99，数值越大优先级越高；普通任务（CFS）为0，实时任务永远优先于普通任务调度。

1.2 RT 限流（RT Throttling）核心定义

RT 限流：内核通过 ** 周期（period）+ 配额（runtime）** 约束实时任务 CPU 占用，当实时任务在一个周期内耗尽配额，内核将对应 CPU 运行队列标记为rt_throttled=1（限流态），暂停所有实时任务调度，直到下一个周期重置配额后解除限流（rt_throttled=0）。

1.3 关键数据结构与参数

（1）全局配置参数（/proc/sys/kernel）

sched_rt_period_us ：限流周期（默认1000000μs=1s） sched_rt_runtime_us ：周期内实时任务总配额（默认950000μs=0.95s）

• 配额 - 1：禁用限流（实时任务可 100% 占用 CPU，生产环境慎用）
• 默认 95%/5% 分配：保障系统至少 5% CPU 处理普通任务、内核线程、SSH 等基础服务

（2）内核核心结构（kernel/sched/sched.h）

// 实时运行队列（per-CPU） struct rt_rq { raw_spinlock_t rt_runtime_lock; u64 rt_time; // 本周期已消耗实时时间（ns） int rt_throttled; // 限流标志：1=限流，0=正常 u64 rt_runtime; // 当前周期可用配额（ns） u64 rt_period; // 限流周期（ns） struct list_head active[RT_NUM_PRIO]; // 实时任务优先级队列 // ... }; // 实时带宽控制结构 struct rt_bandwidth { struct hrtimer rt_period_timer; // 周期重置定时器 ktime_t rt_period; // 周期时长 u64 rt_runtime; // 周期配额 raw_spinlock_t rt_bandwidth_lock; // ... };

rt_throttled是整个限流机制的状态核心，所有调度决策都依赖此标志判断。

1.4 限流核心流程

1. 周期计时：内核以rt_period为循环窗口，启动高精度定时器
2. 时间累计：实时任务运行时，内核在时钟中断（tick）持续累加rt_time
3. 触发限流：rt_time > rt_runtime→ 置rt_throttled=1，暂停实时任务调度
4. 周期重置：定时器到期 → 扣除已用配额、重置rt_time→ 置rt_throttled=0，恢复调度

二、环境准备（可复现实验环境）

2.1 软硬件要求

• CPU：x86_64（Intel/AMD），支持 SMP（多核便于观察单核心限流）
• 内核：Linux 4.19+ / 5.4+ / 5.10+（主流 LTS，本文基于 5.10.0-116-generic）
• 系统：Ubuntu 20.04 / CentOS 8 / Debian 11（RT 补丁非必需）
• 工具：gcc、make、trace-cmd、ftrace、procps、htop

2.2 内核配置检查

# 确认RT调度与带宽控制开启 zcat /proc/config.gz | grep -E "CONFIG_RT_GROUP_SCHED|CONFIG_SCHED_DEBUG" # 预期输出： CONFIG_RT_GROUP_SCHED=y CONFIG_SCHED_DEBUG=y

2.3 安装依赖工具

# Ubuntu/Debian apt install -y gcc make trace-cmd ftrace htop sysstat # CentOS/RHEL yum install -y gcc make trace-cmd kernel-debug htop sysstat

2.4 环境参数备份（实验前）

# 备份默认RT参数 cat /proc/sys/kernel/sched_rt_period_us > rt_period.bak cat /proc/sys/kernel/sched_rt_runtime_us > rt_runtime.bak # 查看默认值（验证） echo "周期(μs): $(cat /proc/sys/kernel/sched_rt_period_us)" echo "配额(μs): $(cat /proc/sys/kernel/sched_rt_runtime_us)" # 输出：1000000、950000

三、典型应用场景（300 字）

工业机器人运动控制场景：控制器主程序（SCHED_FIFO，优先级 90）负责电机脉冲输出、编码器采样、碰撞检测，要求1ms 内响应，否则会导致电机失步、机械碰撞；同时系统运行 WebUI、日志采集、网络通信等普通任务。

若主程序因驱动 bug 进入死循环，无 RT 限流时会 100% 占用 CPU，普通任务完全阻塞，SSH 无法登录、日志无法写入、紧急停机指令无法接收，造成设备损毁。开启 RT 限流（周期 1s、配额 0.9s）后，主程序耗尽配额会触发rt_throttled=1，暂停 100ms，此期间系统可执行 SSH、停机脚本，实现故障隔离与安全恢复，既保障实时性又避免系统崩溃。

四、实战案例与步骤（代码 + 验证全流程）

4.1 实验目标

1. 编写死循环 RT 任务，触发rt_throttled
2. 观测限流触发、任务暂停、周期重置、解除限流全流程
3. 通过 ftrace/kernel 日志验证内核行为
4. 测试不同参数对限流的影响

4.2 步骤 1：编写 RT 死循环测试程序

rt_throttle_test.c（可直接编译运行）

#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <sched.h> #include <sys/syscall.h> #include <unistd.h> #include <string.h> #define RT_PRIORITY 90 // 高实时优先级 #define CPU_CORE 0 // 绑定CPU0，便于单核心观测 // 实时死循环线程 void *rt_loop_thread(void *arg) { // 绑定CPU0 cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(CPU_CORE, &cpuset); if (pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset) != 0) { perror("pthread_setaffinity_np failed"); exit(1); } // 设置SCHED_FIFO策略 struct sched_param param; param.sched_priority = RT_PRIORITY; if (pthread_setschedparam(pthread_self(), SCHED_FIFO, &param) != 0) { perror("pthread_setschedparam failed（需root权限）"); exit(1); } printf("RT线程启动：PID=%ld, CPU=%d, PRI=%d\n", syscall(SYS_gettid), CPU_CORE, RT_PRIORITY); // 死循环（耗尽RT配额） while (1) { // 空循环，不主动放弃CPU } return NULL; } int main() { if (getuid() != 0) { fprintf(stderr, "错误：必须以root运行\n"); return 1; } pthread_t tid; if (pthread_create(&tid, NULL, rt_loop_thread, NULL) != 0) { perror("pthread_create failed"); return 1; } pthread_join(tid, NULL); return 0; }

编译命令：

gcc -o rt_throttle_test rt_throttle_test.c -lpthread

4.3 步骤 2：调整参数（便于快速触发限流）

默认 1s 周期、0.95s 配额，需等待近 1 秒才触发；缩短周期便于实验观测：

# 设置周期100ms（100000μs），配额30ms（30000μs） echo 100000 > /proc/sys/kernel/sched_rt_period_us echo 30000 > /proc/sys/kernel/sched_rt_runtime_us # 验证 cat /proc/sys/kernel/sched_rt_period_us # 100000 cat /proc/sys/kernel/sched_rt_runtime_us # 30000

4.4 步骤 3：运行测试并观测限流触发

（1）终端 1：运行 RT 测试程序

./rt_throttle_test # 输出：RT线程启动：PID=xxxx, CPU=0, PRI=90

（2）终端 2：监控 dmesg（内核日志）

dmesg -w # 约30ms后输出：sched: RT throttling activated（限流触发）

（3）终端 3：监控 CPU 与 rt_throttled 状态

# 监控CPU0使用率（rt任务占比） watch -n 0.1 "mpstat -P 0 1 1 | grep CPU0" # 监控rt_throttled（需debugfs，root执行） mount -t debugfs none /sys/kernel/debug # 挂载debugfs watch -n 0.1 "cat /sys/kernel/debug/sched/rt_rq0 | grep rt_throttled"

现象：

• 启动后 CPU0 瞬间 100%
• 30ms 后：rt_throttled: 1，CPU0 降至≈0%（RT 任务暂停）
• 100ms（周期）后：rt_throttled: 0，CPU0 恢复 100%
• 循环往复：运行 30ms → 暂停 70ms → 重置 → 再运行

4.5 步骤 4：ftrace 跟踪内核限流流程（深度验证）

# 配置ftrace（跟踪RT限流关键函数） cd /sys/kernel/debug/tracing echo function > current_tracer echo *rt*throttle* sched_rt_runtime_exceeded start_rt_bandwidth > set_ftrace_filter echo 1 > tracing_on # 运行测试程序，捕获日志 ./rt_throttle_test & sleep 0.5 cat trace > ftrace_rt_throttle.log # 停止跟踪 echo 0 > tracing_on

关键日志解析：

# 1. 运行时检查配额（sched_rt_runtime_exceeded） CPU0 .....1 | 123.456 us | sched_rt_runtime_exceeded CPU0 .....1 | 123.457 us | rt_rq->rt_time=30000000ns（30ms，耗尽） CPU0 .....1 | 123.458 us | 触发：rt_rq->rt_throttled = 1 # 2. 置限流后，调度器不再选RT任务 CPU0 .....1 | 123.500 us | pick_next_task_rt CPU0 .....1 | 123.501 us | rt_rq->rt_throttled=1，返回NULL（选CFS任务） # 3. 周期定时器到期，重置配额 CPU0 .....1 | 223.456 us | rt_period_timer（100ms到期） CPU0 .....1 | 223.457 us | rt_rq->rt_time -= 30000000ns（重置） CPU0 .....1 | 223.458 us | rt_rq->rt_throttled = 0（解除限流）

4.6 步骤 5：内核源码关键逻辑（rt.c）

（1）限流触发：sched_rt_runtime_exceeded

// kernel/sched/rt.c static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq) { u64 runtime = sched_rt_runtime(rt_rq); // 已限流：直接返回 if (rt_rq->rt_throttled) return rt_rq_throttled(rt_rq); // 配额≥周期：不限流 if (runtime >= sched_rt_period(rt_rq)) return 0; // 已用时间>配额：触发限流 if (rt_rq->rt_time > runtime) { struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq); if (rt_b->rt_runtime) { rt_rq->rt_throttled = 1; // 核心标志置1 printk_deferred_once("sched: RT throttling activated\n"); } return 1; } return 0; }

（2）解除限流：rt_period_timer 回调

// kernel/sched/rt.c static enum hrtimer_restart rt_period_timer(struct hrtimer *timer) { struct rt_bandwidth *rt_b = container_of(timer, struct rt_bandwidth, rt_period_timer); struct rt_rq *rt_rq = container_of(rt_b, struct rt_rq, rt_bandwidth); u64 runtime, overrun; raw_spin_lock(&rt_rq->rt_runtime_lock); runtime = rt_b->rt_runtime; overrun = div64_u64(rt_rq->rt_time, runtime); // 扣除已用周期，重置rt_time if (overrun) { rt_rq->rt_time -= min(rt_rq->rt_time, overrun * runtime); // 限流态且剩余配额>0：解除限流 if (rt_rq->rt_throttled && rt_rq->rt_time < runtime) { rt_rq->rt_throttled = 0; // 核心标志置0 enqueue_rt_stack(rt_rq); } } // 重启定时器 hrtimer_forward_now(timer, rt_b->rt_period); raw_spin_unlock(&rt_rq->rt_runtime_lock); return HRTIMER_RESTART; }

五、常见问题与解答（实战踩坑）

Q1：设置 sched_rt_runtime_us=-1 后，为何仍有限流？

A：

1. 检查是否开启CONFIG_RT_GROUP_SCHED：cgroup 子系统可能独立配置 RT 配额
2. 验证写入是否成功：cat /proc/sys/kernel/sched_rt_runtime_us确认是 - 1
3. 重启生效：部分内核版本需重启后参数完全生效

Q2：单 CPU 限流，其他 CPU RT 任务也被暂停？

A：否。rt_rq是per-CPU结构，rt_throttled仅影响当前 CPU；多核下仅耗尽配额的 CPU 限流，其他 CPU 正常调度 RT 任务。

Q3：实时任务 I/O 休眠后，rt_time 是否累计？

A：否。仅 ** 运行态（Running）** 累计rt_time；休眠（Interruptible/Uninterruptible）时停止计时，I/O 恢复后继续累计。

Q4：如何定位哪个 RT 任务触发限流？

A：

# 方法1：ftrace跟踪pid echo sched_switch > current_tracer cat trace | grep -E "prev_pid.*SCHED_FIFO|next_pid.*SCHED_FIFO" # 方法2：ps监控高CPU RT任务 ps -eo pid,pri,cmd,pcpu | grep -E "RT|FF" | sort -k 4 -r

Q5：生产环境能否禁用限流（runtime=-1）？

A：仅满足以下条件可禁用：

• RT 任务经过严格测试，无死循环、无限阻塞
• 任务含主动放弃 CPU 逻辑（usleep、pthread_yield）
• 系统无必须保障的普通任务（如纯实时嵌入式场景）

六、实践建议与最佳实践

6.1 生产环境参数配置

• 标准场景：period=1000000（1s）, runtime=950000（0.95s）（默认，安全通用）
• 强实时场景：period=100000（100ms）, runtime=80000（80ms）（降低响应延迟）
• 弱实时 + 多普通任务：period=1000000, runtime=500000（0.5s）（更多资源给 CFS）

永久配置（重启生效）：

# /etc/sysctl.conf kernel.sched_rt_period_us=1000000 kernel.sched_rt_runtime_us=950000 # 加载 sysctl -p

6.2 调试与监控技巧

（1）实时监控脚本（rt_mon.sh）

#!/bin/bash while true; do echo "=== $(date) ===" echo "CPU0 RT状态：" cat /sys/kernel/debug/sched/rt_rq0 | grep -E "rt_throttled|rt_time|rt_runtime" echo "RT进程：" ps -eo pid,pri,pcpu,cmd | grep -E "FF|RR" sleep 0.1 done

（2）限流告警（生产必备）

# 监控dmesg，触发限流时邮件告警 dmesg -w | grep --line-buffered "RT throttling activated" | while read line; do echo "【告警】RT限流触发：$line" | mail -s "RT Throttle Alert" admin@xxx.com done

6.3 任务优化：避免频繁限流

1. 拆分大 RT 任务：长耗时逻辑拆分为多段，中间插入 usleep (1) 释放 CPU
2. 合理优先级：非核心 RT 任务用低优先级（10-30），避免与核心任务抢占配额
3. CPU 隔离：通过isolcpus隔离核心专供 RT 任务，不参与全局限流

七、总结

RT 调度器的rt_throttled限流机制是 Linux 实时性与系统稳定性的平衡核心：通过周期 - 配额模型，既保障实时任务高优先级响应，又避免异常任务独占 CPU 导致系统崩溃。

本文从概念→源码→实验→排错→最佳实践全链路解析：

• 触发条件：rt_time > rt_runtime→rt_throttled=1
• 暂停逻辑：调度器检测到rt_throttled=1，跳过 RT 任务，仅调度 CFS
• 解除机制：周期定时器到期 → 重置rt_time→rt_throttled=0→ 恢复调度

掌握此机制，可有效解决生产环境RT 任务异常导致的系统假死、普通任务饥饿、SSH 失联等问题，是嵌入式、工业控制、实时服务器领域工程师必备的内核调优能力。建议结合 ftrace、debugfs 在测试环境复现流程，将实践经验落地到真实项目中。