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

一、简介在实时系统和云计算环境中资源隔离与公平分配是 Linux 内核调度的核心挑战。当多个任务共享 CPU 资源时某些恶意或失控的任务可能耗尽全部 CPU 时间导致关键任务饥饿Starvation。为此Linux 内核引入了限流机制Throttling通过throttled标志实现对任务组的带宽控制。限流机制的核心价值防止资源滥用限制 cgroup 中任务的 CPU 使用率不超过配额保障关键任务确保实时任务RT在限定带宽内稳定运行多租户隔离在容器化部署Kubernetes/Docker中实现严格的资源边界掌握限流机制对于以下场景至关重要开发实时嵌入式系统工业控制、自动驾驶构建云原生平台的资源管控层进行内核调度算法的学术研究优化容器集群的 QoS 保障策略二、核心概念2.1 CFS完全公平调度器带宽控制CFS 通过cpu.cfs_quota_us和cpu.cfs_period_us两个参数实现限流配额Quota在一个周期内允许使用的 CPU 时间微秒周期Period带宽计算的时间窗口默认 100ms当任务组的 CPU 使用超过quota/period比例时触发限流。2.2 RT实时调度器带宽控制实时任务使用cpu.rt_runtime_us和cpu.rt_period_us参数运行时Runtime周期内允许 RT 任务运行的最大时间周期PeriodRT 带宽计算窗口默认 1sRT 限流更为严格一旦耗尽配额立即被强制限流。2.3 关键术语表术语说明throttled内核标志位表示任务组已被限流throttle_count限流触发次数统计cfs_bandwidthCFS 带宽控制结构体rt_bandwidthRT 带宽控制结构体hrtimer高精度定时器用于解除限流rq-clock运行队列时钟用于精确计时2.4 限流触发与解除流程// 内核中的限流判断逻辑简化示意 if (cfs_b-quota ! RUNTIME_INF cfs_b-runtime 0 !cfs_b-timer_active) { // 触发限流 throttle_cfs_rq(cfs_rq); start_cfs_bandwidth_timer(cfs_b); } // 定时器到期后解除限流 void unthrottle_cfs_rq(struct cfs_rq *cfs_rq) { if (cfs_rq-throttled) { cfs_rq-throttled 0; // 清除标志 enqueue_cfs_rq(cfs_rq); // 重新入队 } }三、环境准备3.1 硬件要求CPUx86_64 或 ARM64 架构支持高精度定时器HPET内存≥4GB用于编译内核和运行测试存储≥50GB 可用空间3.2 软件环境组件版本要求验证命令Linux 内核5.10推荐 6.1 LTSuname -rGCC 编译器9.0gcc --versioncgroup v2必须启用mount | grep cgroup2perf 工具5.10perf --versionbpftool5.10bpftool --version3.3 内核配置检查# 检查 CFS 带宽控制是否编译进内核 grep CONFIG_CFS_BANDWIDTH /boot/config-$(uname -r) # 应输出: CONFIG_CFS_BANDWIDTHy # 检查 RT 带宽控制 grep CONFIG_RT_GROUP_SCHED /boot/config-$(uname -r) # 应输出: CONFIG_RT_GROUP_SCHEDy # 检查 cgroup v2 支持 grep CONFIG_CGROUP_V2 /boot/config-$(uname -r) # 应输出: CONFIG_CGROUP_V2y3.4 实验环境搭建脚本#!/bin/bash # setup_env.sh - 限流机制实验环境搭建 # 创建实验目录 mkdir -p ~/throttling-lab/{src,logs,configs} cd ~/throttling-lab # 安装必要工具 sudo apt-get update sudo apt-get install -y \ linux-tools-common \ linux-tools-generic \ cgroup-tools \ stress-ng \ sysstat \ kernelshark # 挂载 cgroup v2如未挂载 if ! mountpoint -q /sys/fs/cgroup; then sudo mount -t cgroup2 none /sys/fs/cgroup fi # 创建测试用的 cgroup 层级 sudo mkdir -p /sys/fs/cgroup/throttling-test echo cpu | sudo tee /sys/fs/cgroup/cgroup.subtree_control echo 环境准备完成工作目录: ~/throttling-lab四、应用场景在金融高频交易系统中限流机制发挥着关键作用。假设某券商的撮合引擎部署在 Kubernetes 集群中需要同时运行以下组件核心撮合服务RT 优先级处理订单匹配要求延迟 10μs风控计算模块CFS 优先级实时计算风险敞口CPU 限制 20%日志采集进程CFS 优先级异步写入磁盘CPU 限制 10%通过 cgroup v2 的层级结构运维人员可以为每个 Pod 设置严格的 CPU 配额。当风控模块因突发流量试图占用更多 CPU 时CFS 限流器会在 100ms 周期内将其限流确保撮合服务始终获得所需的 RT 带宽。同时系统管理员可以通过throttle_count监控指标在 Prometheus 中设置告警当限流频率超过阈值时自动扩容。这种机制在自动驾驶域控制器中同样重要确保传感器数据处理任务不会挤占车辆控制算法的执行时间满足 ISO 26262 的功能安全要求。五、实际案例与步骤5.1 案例一CFS 限流触发与监控步骤 1创建带带宽限制的 cgroup# 创建 cgroup 并设置 10% CPU 限制100ms 周期内最多使用 10ms sudo mkdir -p /sys/fs/cgroup/throttling-test/cfs-limited # 设置配额10ms / 100ms 10% CPU echo 10000 | sudo tee /sys/fs/cgroup/throttling-test/cfs-limited/cpu.max # 输出: 10000 100000 # 验证配置 cat /sys/fs/cgroup/throttling-test/cfs-limited/cpu.max # 预期输出: 10000 100000步骤 2启动 CPU 密集型任务并监控#!/bin/bash # cfs_throttle_demo.sh - CFS 限流演示 CGROUP_PATH/sys/fs/cgroup/throttling-test/cfs-limited PID_FILE/tmp/stress.pid # 清理旧 cgroup sudo rmdir $CGROUP_PATH 2/dev/null sudo mkdir -p $CGROUP_PATH # 设置 50ms/100ms 50% CPU 限制便于观察 echo 50000 100000 | sudo tee $CGROUP_PATH/cpu.max # 启动 stress-ng 消耗 100% CPU4 个线程 stress-ng --cpu 4 --cpu-method matrixprod --timeout 60s STRESS_PID$! echo $STRESS_PID $PID_FILE # 将进程加入 cgroup echo $STRESS_PID | sudo tee $CGROUP_PATH/cgroup.procs echo 实时监控限流状态每 2 秒采样 for i in {1..10}; do echo --- 采样 $i --- echo 当前 CPU 统计: cat $CGROUP_PATH/cpu.stat echo 限流次数: grep nr_throttled $CGROUP_PATH/cpu.stat echo 实际 CPU 使用率: ps -p $STRESS_PID -o %cpu,cmd sleep 2 done # 清理 kill $STRESS_PID 2/dev/null sudo rmdir $CGROUP_PATH预期输出分析--- 采样 1 --- 当前 CPU 统计: usage_usec 45000 user_usec 45000 system_usec 0 nr_periods 1 nr_throttled 0 -- 尚未触发限流 throttled_usec 0 --- 采样 5 --- nr_periods 5 nr_throttled 3 -- 已触发 3 次限流 throttled_usec 150000 -- 累计被限流 150ms步骤 3使用 perf 追踪限流事件# 录制 sched 事件捕获限流相关的上下文切换 sudo perf record -e sched:sched_stat_throttled \ -e sched:sched_cfs_bandwidth_sleeper \ -a sleep 10 # 生成报告 sudo perf script --header throttling_events.log # 分析限流模式 grep throttled throttling_events.log | head -205.2 案例二RT 限流的严格边界控制步骤 1配置 RT 带宽参数# 查看当前 RT 带宽设置系统级 cat /proc/sys/kernel/sched_rt_period_us # 默认: 1000000 (1秒) cat /proc/sys/kernel/sched_rt_runtime_us # 默认: 950000 (0.95秒即 RT 最多占用 95% CPU) # 为实验安全先放宽限制仅测试环境 echo -1 | sudo tee /proc/sys/kernel/sched_rt_runtime_us # -1 表示不限制便于测试步骤 2创建 RT 任务的 cgroup 限制#!/bin/bash # rt_throttle_demo.sh - RT 限流严格测试 CGROUP_PATH/sys/fs/cgroup/throttling-test/rt-limited sudo mkdir -p $CGROUP_PATH # 启用 CPU 控制器 echo cpu | sudo tee /sys/fs/cgroup/cgroup.subtree_control # 设置 RT 带宽100ms 周期内最多运行 20ms20% # 注意RT 使用 cpu.rt.max 接口cgroup v2 echo 20000 100000 | sudo tee $CGROUP_PATH/cpu.rt.max # 编译 RT 测试程序 cat /tmp/rt_spin.c EOF #define _GNU_SOURCE #include stdio.h #include stdlib.h #include sched.h #include unistd.h #include sys/resource.h int main() { // 设置为 FIFO 实时调度优先级 50 struct sched_param param { .sched_priority 50 }; if (sched_setscheduler(0, SCHED_FIFO, param) -1) { perror(sched_setscheduler failed); exit(1); } printf(RT task started on CPU %d\n, sched_getcpu()); // 无限循环消耗 CPU volatile unsigned long long counter 0; while (1) { counter; // 每 1 亿次循环打印一次避免输出过多 if (counter % 100000000ULL 0) { printf(Counter: %llu\n, counter); } } return 0; } EOF gcc -o /tmp/rt_spin /tmp/rt_spin.c -O2 # 启动 RT 任务并加入 cgroup sudo /tmp/rt_spin RT_PID$! echo $RT_PID | sudo tee $CGROUP_PATH/cgroup.procs echo RT 任务 $RT_PID 已启动限制为 20% CPU echo 监控限流状态... # 监控循环 for i in {1..5}; do sleep 2 echo --- 第 $i 次检查 --- cat $CGROUP_PATH/cpu.stat ps -p $RT_PID -o pid,rtprio,%cpu,stat,cmd done # 强制终止并清理 sudo kill -9 $RT_PID 2/dev/null sudo rmdir $CGROUP_PATH步骤 3内核态限流逻辑分析// 内核代码分析kernel/sched/rt.c 中的关键函数 /* * 检查 RT 任务是否超过带宽限制 * 返回 true 表示需要限流 */ 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-rt_runtime sched_rt_period(rt_rq); // 检查是否耗尽配额 if (runtime sched_rt_runtime(rt_rq) runtime ! RUNTIME_INF) { // 触发限流 rt_rq-rt_throttled 1; return 1; } return 0; } /* * 解除限流的定时器回调 */ static enum hrtimer_restart sched_rt_period_timer(struct hrtimer *timer) { struct rt_bandwidth *rt_b container_of(timer, ...); // 重新填充配额 rt_b-rt_runtime rt_b-rt_runtime_copy; // 遍历所有运行队列解除限流 for_each_cpu(cpu, rt_b-rt_cpus) { struct rt_rq *rt_rq cpu_rq(cpu)-rt; if (rt_rq-rt_throttled) { rt_rq-rt_throttled 0; enqueue_rt_rq(rt_rq); // 重新入队 } } return HRTIMER_RESTART; }5.3 案例三编写内核模块探测限流事件/* * throttle_probe.c - 内核模块监控限流事件 * 编译make -C /lib/modules/$(uname -r)/build M$(pwd) modules */ #include linux/module.h #include linux/kprobes.h #include linux/sched.h #include linux/cgroup.h static struct kprobe kp_throttle, kp_unthrottle; /* 探测限流触发点 */ static int handler_throttle(struct kprobe *p, struct pt_regs *regs) { struct cfs_rq *cfs_rq (struct cfs_rq *)regs-di; // x86_64 第一个参数 pr_info([THROTTLE] CFS_RQ throttled! cpu%d, throttled%d\n, cfs_rq-rq-cpu, cfs_rq-throttled); // 记录调用栈 dump_stack(); return 0; } /* 探测限流解除点 */ static int handler_unthrottle(struct kprobe *p, struct pt_regs *regs) { struct cfs_rq *cfs_rq (struct cfs_rq *)regs-di; pr_info([UNTHROTTLE] CFS_RQ unthrottled! cpu%d\n, cfs_rq-rq-cpu); return 0; } static int __init throttle_probe_init(void) { int ret; // 探测 throttle_cfs_rq 函数 kp_throttle.symbol_name throttle_cfs_rq; kp_throttle.pre_handler handler_throttle; ret register_kprobe(kp_throttle); if (ret 0) { pr_err(register_kprobe (throttle) failed: %d\n, ret); return ret; } // 探测 unthrottle_cfs_rq 函数 kp_unthrottle.symbol_name unthrottle_cfs_rq; kp_unthrottle.pre_handler handler_unthrottle; ret register_kprobe(kp_unthrottle); if (ret 0) { unregister_kprobe(kp_throttle); pr_err(register_kprobe (unthrottle) failed: %d\n, ret); return ret; } pr_info(Throttling probe module loaded\n); return 0; } static void __exit throttle_probe_exit(void) { unregister_kprobe(kp_throttle); unregister_kprobe(kp_unthrottle); pr_info(Throttling probe module unloaded\n); } module_init(throttle_probe_init); module_exit(throttle_probe_exit); MODULE_LICENSE(GPL); MODULE_DESCRIPTION(CFS Throttling Event Probe);Makefileobj-m throttle_probe.o all: make -C /lib/modules/$(shell uname -r)/build M$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M$(PWD) clean5.4 案例四使用 eBPF 实时追踪限流// throttle_trace.bpf.c - eBPF 程序追踪限流事件 #include vmlinux.h #include bpf/bpf_helpers.h #include bpf/bpf_tracing.h #define MAX_ENTRIES 1024 struct throttle_event { u32 pid; u32 cpu; u64 timestamp; u64 throttled_usec; u8 type; // 0throttle, 1unthrottle }; struct { __uint(type, BPF_MAP_TYPE_RINGBUF); __uint(max_entries, 256 * 1024); } rb SEC(.maps); // 追踪 throttle_cfs_rq 函数 SEC(kprobe/throttle_cfs_rq) int BPF_KPROBE(trace_throttle, struct cfs_rq *cfs_rq) { struct throttle_event *e; e bpf_ringbuf_reserve(rb, sizeof(*e), 0); if (!e) return 0; e-type 0; e-timestamp bpf_ktime_get_ns(); e-cpu BPF_CORE_READ(cfs_rq, rq, cpu); // 读取 throttled 计时器值 struct cfs_bandwidth *cfs_b BPF_CORE_READ(cfs_rq, cfs_bandwidth); e-throttled_usec BPF_CORE_READ(cfs_b, throttled_time); bpf_ringbuf_submit(e, 0); return 0; } // 追踪 unthrottle_cfs_rq 函数 SEC(kprobe/unthrottle_cfs_rq) int BPF_KPROBE(trace_unthrottle, struct cfs_rq *cfs_rq) { struct throttle_event *e; e bpf_ringbuf_reserve(rb, sizeof(*e), 0); if (!e) return 0; e-type 1; e-timestamp bpf_ktime_get_ns(); e-cpu BPF_CORE_READ(cfs_rq, rq, cpu); e-throttled_usec 0; bpf_ringbuf_submit(e, 0); return 0; } char LICENSE[] SEC(license) GPL;用户态加载程序Python#!/usr/bin/env python3 # throttle_monitor.py - 加载 eBPF 程序并输出限流事件 from bcc import BPF import sys # 加载 BPF 程序 b BPF(src_filethrottle_trace.bpf.c) # 打印表头 print(f{TIME:20} {CPU:5} {TYPE:12} {THROTTLED_US:15}) print(- * 55) # 处理 ringbuf 事件 def handle_event(ctx, data, size): event b[rb].event(data) ts event.timestamp / 1e9 # 转换为秒 type_str THROTTLE if event.type 0 else UNTHROTTLE print(f{ts:20.6f} {event.cpu:5} {type_str:12} {event.throttled_usec:15}) b[rb].open_ring_buffer(handle_event) # 轮询事件 while True: try: b.ring_buffer_poll() except KeyboardInterrupt: sys.exit(0)六、常见问题与解答Q1为什么设置了cpu.max但任务仍然占用 100% CPU原因cgroup v2 的cpu.max格式为quota period如果写入格式错误如只写配额值不写周期内核可能使用默认值导致限制失效。验证与修复# 错误示例缺少周期值 echo 50000 cpu.max # 可能不生效 # 正确格式 echo 50000 100000 cpu.max # 配额 周期 # 验证当前值 cat cpu.max # 应输出两个数字最大配额 和 周期Q2RT 任务被限流后为什么无法自动恢复原因RT 限流依赖全局带宽计时器如果系统中有多个 RT cgroup 且总带宽超过系统限制可能导致所有 RT 任务被限流后无法及时解除。诊断命令# 检查全局 RT 带宽使用情况 cat /proc/sched_debug | grep -A 5 rt_rq # 查看每个 CPU 的 RT 运行队列状态 for cpu in /sys/devices/system/cpu/cpu[0-9]*; do cat $cpu/sched_rt_runtime_us 2/dev/null doneQ3如何区分 CFS 限流和 RT 限流代码诊断# 查看限流类型统计 cat /sys/fs/cgroup/$CGROUP_PATH/cpu.stat # CFS 限流指标 # nr_periods - 周期计数 # nr_throttled - 限流次数 # throttled_usec - 限流时间 # RT 限流指标cgroup v2 # rt_time - RT 任务运行时间 # rt_throttled - RT 限流次数Q4限流导致的性能抖动如何优化解决方案增大周期值减少限流频率牺牲精度换取平滑性echo 100000 500000 cpu.max # 100ms/500ms 20%周期更长使用 burst 机制内核 5.14# 允许突发使用累积的配额 echo 100000 100000 500000 cpu.max # 配额 周期 burst绑定 CPU 避免跨核迁移taskset -cp 2 $PID # 绑定到 CPU 2七、实践建议与最佳实践7.1 调试技巧使用 ftrace 追踪限流路径# 启用 sched 追踪点 echo 1 /sys/kernel/debug/tracing/events/sched/sched_stat_throttled/enable echo 1 /sys/kernel/debug/tracing/events/sched/sched_cfs_bandwidth_sleeper/enable # 实时查看 cat /sys/kernel/debug/tracing/trace_pipe | grep -E (throttle|bandwidth) # 录制并分析 echo /sys/kernel/debug/tracing/trace # 清空 sleep 5 cat /sys/kernel/debug/tracing/trace throttle_trace.log7.2 性能优化建议场景建议配置说明低延迟实时任务cpu.rt.max950000 1000000保留 5% 给 CFS 任务批量数据处理cpu.max800000 1000000限制 80%避免影响其他服务开发测试环境cpu.max50000 100000严格限制模拟资源紧张混合负载生产启用cpu.uclamp.min/max配合 util clamp 精细化控制7.3 监控告警脚本#!/bin/bash # throttle_alert.sh - 限流监控告警 CGROUP_BASE/sys/fs/cgroup ALERT_THRESHOLD10 # 10秒内限流次数阈值 LOG_FILE/var/log/throttling_alerts.log check_cgroup() { local cg$1 local stats$cg/cpu.stat if [[ -f $stats ]]; then local throttled$(grep nr_throttled $stats | awk {print $2}) local periods$(grep nr_periods $stats | awk {print $2}) if [[ $throttled -gt $ALERT_THRESHOLD ]]; then echo [$(date)] ALERT: $cg throttled $throttled times in $periods periods $LOG_FILE # 发送告警示例写入 systemd journal logger -p user.err CPU throttling detected: $cg fi fi } # 递归检查所有 cgroup find $CGROUP_BASE -type d -name cpu.stat -exec dirname {} \; | while read cg; do check_cgroup $cg done八、总结与应用场景本文深入剖析了 Linux 调度子系统中的限流机制Throttling通过 CFS 和 RT 两个调度类的实战案例展示了throttled标志的触发条件、内核处理流程及解除机制。关键要点包括限流触发条件当任务组在周期内消耗的 CPU 时间超过quota时throttled标志置位任务被强制从运行队列移除定时器驱动恢复内核使用高精度定时器hrtimer在周期边界重置配额清除throttled标志并重新入队监控与诊断通过 cgroup v2 的cpu.stat接口、eBPF 探针和 ftrace 可实现全链路追踪典型应用场景云原生资源管控Kubernetes 的 CPU limit 依赖 CFS 限流实现硬约束实时系统保障工业控制器中通过 RT 限流防止非关键任务干扰 PLC 循环多租户安全隔离SaaS 平台利用 cgroup 层级结构实现租户间的资源边界学术研究方向调度算法优化、虚拟化环境下的公平性量化分析建议读者在内核版本 5.15的环境中复现实验结合kernel/sched/fair.c和kernel/sched/rt.c的源码阅读深入理解throttle_cfs_rq()和unthrottle_cfs_rq()的调用上下文。对于容器化部署场景务必注意 cgroup v1 与 v2 的接口差异生产环境建议统一使用 cgroup v2 以获得更一致的限流行为