一、简介

在工业控制、自动驾驶、实时音视频、航天嵌入式实时服务器等场景中，Linux 实时任务（SCHED_FIFO/SCHED_RR）具备高抢占、低延迟的调度特性，一旦无限制运行，极易独占 CPU 核心，导致系统普通业务、其他租户实时任务出现饥饿、卡顿甚至雪崩故障。

传统 CFS 调度器的 CPU 带宽限制仅针对普通分时进程，无法管控 RT 高优先级实时任务，这也是生产环境中多业务混部、容器多租户部署、工控多进程实时架构的核心痛点。而 Linux 内核从 2.6.37 版本开始引入CONFIG_RT_GROUP_SCHED配置，基于rt_bandwidth结构体实现RT 任务组级别的 CPU 带宽限流，通过rt_period_us调度周期与rt_runtime_us最大运行时长双重参数，精准限制单个任务组内所有 RT 任务的总 CPU 使用率，从内核调度层面实现实时任务的资源隔离与配额管控。

掌握rt_bandwidth底层原理、配置方法、源码逻辑与排错技巧，是 Linux 内核开发、实时系统运维、容器云多租户架构设计、工控 Linux 定制开发工程师的必备能力。既能解决生产环境 RT 任务抢占 CPU 的稳定性问题，也能为实时操作系统论文调研、内核调度子系统课题研究、企业级实时 Linux 方案设计提供理论与实战支撑。本文从资深内核工程师视角，结合内核源码、实操命令、案例代码，全方位拆解 rt_bandwidth 机制，全程落地可复现。

二、核心概念

2.1 RT 调度基础概念

1. 实时调度策略Linux RT 调度包含SCHED_FIFO（先来先服务实时调度）和SCHED_RR（时间片轮转实时调度），优先级范围 1~99，优先级高于普通 CFS 分时进程，可强抢占 CPU，无主动让出时会持续占用核心。

2. RT Group Scheduling内核编译选项CONFIG_RT_GROUP_SCHED，开启后支持基于 cgroup 对 RT 任务分组管控，不再以单进程为限流单位，而是以任务组为整体做带宽统计与节流。

2.2 rt_bandwidth 核心结构体

rt_bandwidth是内核管控 RT 任务组带宽的核心数据结构，定义于kernel/sched/rt.c，核心字段如下：

struct rt_bandwidth {
    /* 调度周期：微秒为单位 */
    ktime_t         rt_period;
    /* 周期内允许最大运行时长：微秒为单位 */
    ktime_t         rt_runtime;
    /* 周期内已消耗的CPU运行时间 */
    ktime_t         rt_time;
    /* 节流阈值标记 */
    int             rt_throttled;
    /* 周期定时器，用于重置带宽配额 */
    struct hrtimer  rt_period_timer;
};

• rt_period_us：带宽统计周期，默认 1000000us（1 秒）；
• rt_runtime_us：单个周期内任务组所有 RT 任务可占用的最大 CPU 时长，决定 CPU 配额占比；
• rt_throttled：节流标记，置 1 时组内 RT 任务被暂停调度，等待下一个周期重置配额。

2.3 关键术语解释

1. RT 带宽节流（RT Throttling）当任务组内所有 RT 任务累计运行时长超过rt_runtime_us配额时，内核触发节流，暂时剥夺该组 RT 任务的 CPU 调度权，直到调度周期刷新。
2. 全局 RT 带宽限制/proc/sys/kernel/sched_rt_runtime_us 系统全局 RT 总配额，所有 RT 任务组的rt_runtime_us总和不能超过该全局值，避免整机 RT 任务占满 CPU。
3. cgroup cpu 子系统 RT 接口cgroup v1 cpu 子系统下专属 RT 配置文件：cpu.rt_period_us、cpu.rt_runtime_us，用户态直接写入配置即可生效，无需修改内核源码。

三、环境准备

3.1 软硬件环境要求

环境类型	版本 / 配置要求
操作系统	Ubuntu 20.04/22.04、CentOS 7/8、Linux 内核 4.19~6.5
内核配置	开启CONFIG_RT_GROUP_SCHED=y、CONFIG_CGROUPS=y、CONFIG_CPUSETS=y
硬件	x86_64 物理机 / 虚拟机，至少 2 核 CPU，2G 以上内存
工具依赖	libcgroup、sysctl、gcc、make、git、trace-cmd、perf

3.2 环境检查与配置

3.2.1 检查内核是否支持 RT 任务组调度

执行以下命令校验内核编译配置：

# 查看是否开启RT_GROUP_SCHED
zcat /proc/config.gz | grep RT_GROUP_SCHED

正常输出：CONFIG_RT_GROUP_SCHED=y，若为n则需重新编译内核开启该选项。

3.2.2 安装依赖工具

# Ubuntu/Debian
apt update && apt install -y libcgroup-tools gcc make perf trace-cmd

# CentOS/RHEL
yum install -y libcgroup-tools gcc make perf

3.2.3 挂载 cgroup cpu 子系统

默认系统已自动挂载，手动挂载命令备用：

mkdir -p /sys/fs/cgroup/cpu
mount -t cgroup -o cpu none /sys/fs/cgroup/cpu

3.2.4 全局 RT 参数初始化

修改系统全局 RT 最大运行配额，限制整机 RT 任务最大 CPU 占用：

# 设置全局周期1s，全局RT最大运行时长800ms
echo 1000000 > /proc/sys/kernel/sched_rt_period_us
echo 800000 > /proc/sys/kernel/sched_rt_runtime_us

# 永久生效（重启保留）
cat >> /etc/sysctl.conf << EOF
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 800000
EOF
sysctl -p

四、应用场景

rt_bandwidth RT 任务组带宽控制核心落地场景集中在实时系统多租户隔离、工控业务混部、实时容器部署三大方向。在工业物联网网关设备中，网关同时运行设备采集、协议转发、日志上报三类 RT 实时进程，通过创建独立 cgroup 任务组，分别限制各组 RT 任务 CPU 占用率，防止某一路采集进程死循环独占核心，保障其他实时业务低延迟运行；在云服务器多租户实时业务场景，云厂商为每个租户创建专属 RT 任务组，通过 rt_runtime_us 配额限制租户实时音视频、交易撮合进程的 CPU 上限，实现租户间资源强隔离，避免单租户恶意抢占影响其他租户；另外在 Linux 工控定制系统、自动驾驶车载系统中，将车身控制、雷达感知、人机交互 RT 任务分组限流，既保证高优先级任务调度时效，又避免实时任务无限制消耗 CPU，兼顾系统稳定性与实时性。

五、实际案例与步骤

5.1 案例目标

创建两个 RT 任务组rt_group1、rt_group2，配置不同 CPU 带宽配额，分别绑定高负载 SCHED_FIFO 实时进程，验证 rt_bandwidth 节流效果，同时结合内核源码解析调度流程。

5.2 步骤 1：创建 RT 任务组

# 进入cgroup cpu子系统目录
cd /sys/fs/cgroup/cpu

# 创建两个实时任务组
mkdir rt_group1 rt_group2

5.3 步骤 2：配置任务组 RT 带宽参数

配置规则：周期固定 1 秒 (1000000us)，rt_group1 限制 CPU 占比 20%，rt_group2 限制 30%。

# 配置rt_group1：周期1s，运行配额200ms
echo 1000000 > rt_group1/cpu.rt_period_us
echo 200000 > rt_group1/cpu.rt_runtime_us

# 配置rt_group2：周期1s，运行配额300ms
echo 1000000 > rt_group2/cpu.rt_period_us
echo 300000 > rt_group2/cpu.rt_runtime_us

# 校验配置是否生效
cat rt_group1/cpu.rt_period_us rt_group1/cpu.rt_runtime_us
cat rt_group2/cpu.rt_period_us rt_group2/cpu.rt_runtime_us

5.4 步骤 3：编写高负载 RT 测试程序

编写 C 语言代码，创建死循环 SCHED_FIFO 实时进程，模拟高负载 RT 业务，代码可直接编译运行：

// rt_load.c 实时高负载测试程序
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sched.h>
#include <pthread.h>

// 设置进程为SCHED_FIFO实时调度策略
void set_rt_priority(int prio)
{
    struct sched_param param;
    param.sched_priority = prio;
    // 配置实时调度策略
    if (sched_setscheduler(0, SCHED_FIFO, &param) < 0) {
        perror("sched_setscheduler failed");
        exit(1);
    }
}

// 死循环占用CPU
void cpu_forever_load(void)
{
    while (1) {
        // 空循环，纯占用CPU
    }
}

int main(int argc, char *argv[])
{
    // 设置实时优先级50（1~99）
    set_rt_priority(50);
    printf("RT进程启动，PID: %d, 优先级:50\n", getpid());
    
    // 持续占用CPU
    cpu_forever_load();
    return 0;
}

编译命令：

gcc rt_load.c -o rt_load -lpthread

5.5 步骤 4：绑定进程到对应 RT 任务组

# 终端1：启动测试进程
./rt_load
# 记录输出的PID，假设为12345

# 将PID加入rt_group1任务组
echo 12345 > /sys/fs/cgroup/cpu/rt_group1/tasks

# 终端2：启动第二个测试进程
./rt_load
# 假设PID为67890，加入rt_group2
echo 67890 > /sys/fs/cgroup/cpu/rt_group2/tasks

5.6 步骤 5：观测带宽节流与 CPU 占用

5.6.1 查看 CPU 占用率

top -H -p 12345,67890

现象：两个 RT 进程不会占满 100% CPU，rt_group1 进程稳定占用 20% 左右，rt_group2 占用 30% 左右，超出配额后被内核节流暂停。

5.6.2 查看任务组节流状态

# 查看是否触发节流，rt_throttled为1表示已限流
cat /sys/fs/cgroup/cpu/rt_group1/cpu.rt_throttled
cat /sys/fs/cgroup/cpu/rt_group2/cpu.rt_throttled

5.7 步骤 6：内核源码关键流程解析

5.7.1 rt_bandwidth 初始化函数

内核创建任务组时调用init_rt_bandwidth初始化带宽参数：

// kernel/sched/rt.c
void init_rt_bandwidth(struct rt_bandwidth *rt_b,
                       ktime_t period, ktime_t runtime)
{
    // 初始化周期和运行时长
    rt_b->rt_period = period;
    rt_b->rt_runtime = runtime;
    rt_b->rt_time = 0;
    rt_b->rt_throttled = 0;

    // 初始化高精度定时器，周期重置带宽配额
    hrtimer_init(&rt_b->rt_period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
    rt_b->rt_period_timer.function = rt_bandwidth_timer;
}

代码说明：该函数为每个 RT 任务组初始化定时器与带宽统计字段，定时器到期后清空已运行时间，解除节流状态。

5.7.2 RT 任务运行时间统计与节流判断

// kernel/sched/rt.c
static void rt_account_runtime(struct rt_bandwidth *rt_b, u64 delta)
{
    // 累加组内RT任务运行时长
    rt_b->rt_time += delta;

    // 判断是否超过配额，触发节流
    if (rt_b->rt_time >= rt_b->rt_runtime && !rt_b->rt_throttled) {
        rt_b->rt_throttled = 1;
        // 暂停该任务组RT任务调度
        rt_throttle_group(rt_b);
        // 启动周期定时器
        hrtimer_start(&rt_b->rt_period_timer, rt_b->rt_period, HRTIMER_MODE_REL);
    }
}

代码说明：每次 RT 任务调度退出时，内核调用该函数统计运行时间，超出rt_runtime_us则标记节流，暂停组内所有 RT 任务调度。

5.7.3 周期定时器回调重置配额

// kernel/sched/rt.c
static enum hrtimer_restart rt_bandwidth_timer(struct hrtimer *timer)
{
    struct rt_bandwidth *rt_b = container_of(timer,
                    struct rt_bandwidth, rt_period_timer);

    // 清空已运行时间，解除节流
    rt_b->rt_time = 0;
    rt_b->rt_throttled = 0;
    // 恢复任务组调度
    rt_unthrottle_group(rt_b);

    return HRTIMER_NORESTART;
}

5.8 步骤 7：关闭 RT 带宽限制

测试完成后，删除任务组、恢复全局参数：

# 删除任务组
rmdir /sys/fs/cgroup/cpu/rt_group1
rmdir /sys/fs/cgroup/cpu/rt_group2

# 恢复全局RT默认配置
echo 1000000 > /proc/sys/kernel/sched_rt_period_us
echo 950000 > /proc/sys/kernel/sched_rt_runtime_us

六、常见问题与解答

6.1 问题 1：配置 cpu.rt_runtime_us 后不生效，RT 进程仍占满 CPU

原因：内核未开启CONFIG_RT_GROUP_SCHED，cgroup RT 限流机制未加载。解决：通过zcat /proc/config.gz | grep RT_GROUP_SCHED校验，重新编译内核开启该配置；同时确认进程是SCHED_FIFO/SCHED_RR策略，普通 CFS 进程不受 RT 带宽管控。

6.2 问题 2：写入 cpu.rt_runtime_us 提示权限拒绝

原因：普通用户无 cgroup 文件系统写入权限，或挂载目录权限受限。解决：全程使用 root 用户操作；若需普通用户配置，修改 cgroup 目录权限chmod 777 /sys/fs/cgroup/cpu -R。

6.3 问题 3：任务组 rt_runtime_us 总和超过全局 sched_rt_runtime_us

现象：配置生效失败，系统日志提示 RT 带宽溢出。原因：所有 RT 任务组的 rt_runtime_us 累加值不能超过全局sched_rt_runtime_us。解决：合理拆分各任务组配额，下调单个组 runtime 值，或适当调高全局 sched_rt_runtime_us。

6.4 问题 4：RT 进程加入任务组后直接卡顿、无法运行

原因：rt_runtime_us 设置过小，进程启动后瞬间耗尽配额，直接触发永久节流。解决：调高cpu.rt_runtime_us配额，保证基础运行时长；优先以 1s 为周期，按百分比配置配额（如 10%=100000us）。

6.5 问题 5：多核 CPU 下 RT 带宽限制不准确

原因：rt_bandwidth 默认按单 CPU 核心统计，多核环境下配额会按 CPU 核心数翻倍。解决：多核心场景按核心数折算配额，4 核服务器若需总占用 20%，单组 rt_runtime_us 设置为200000 / 4。

七、实践建议与最佳实践

7.1 配置规范最佳实践

1. 周期统一标准化：所有 RT 任务组固定使用 1000000us（1 秒）作为 rt_period_us，便于按百分比核算 CPU 配额，降低维护成本。
2. 配额预留冗余：全局 sched_rt_runtime_us 不设置超过 900000us，预留 10% CPU 给系统内核线程、中断处理，避免整机无空闲资源。
3. 分层分组管控：按业务优先级划分 RT 任务组，核心业务分配高 runtime 配额，非核心实时业务限制低配额，实现分级隔离。

7.2 调试与排错技巧

1. 通过 dmesg 查看 RT 节流日志

dmesg | grep -i rt_throttle

可直接查看内核触发 RT 任务组节流的时间与任务组信息，定位配额溢出问题。

1. perf 跟踪 RT 调度事件

perf record -g sleep 10
perf report

跟踪 RT 任务调度、rt_bandwidth 定时器触发、节流函数调用栈，适合内核源码调试与性能分析。

1. trace-cmd 抓取调度轨迹

trace-cmd record -p function_graph -g rt_account_runtime
trace-cmd report

精准抓取 rt_bandwidth 时间统计、节流触发、定时器回调全过程，适合论文调研与内核流程分析。

7.3 性能优化建议

1. 避免频繁修改 RT 配额：运行中频繁读写 cpu.rt_runtime_us 会触发内核调度重构，业务稳定后固化配置，不动态变更。
2. 绑定 RT 任务到指定核心：配合 cgroup cpuset 子系统，将 RT 任务组绑定独占 CPU 核心，减少上下文切换，提升实时性与限流精准度。
3. 禁用不必要的 RT 任务：系统无关后台进程禁止设置 SCHED_FIFO/SCHED_RR 策略，减少 rt_bandwidth 统计开销。

7.4 生产环境落地规范

工业工控、容器云多租户场景下，建议通过 systemd 服务、容器运行时自动创建 cgroup RT 任务组，固化 rt_period_us 与 rt_runtime_us 配置；同时加入监控告警，定时采集 cpu.rt_throttled 状态，一旦触发节流超过阈值，及时告警调整配额，避免业务延迟超标。

八、总结与应用场景回顾

本文从底层概念、环境搭建、实操案例、内核源码、排错优化全维度拆解了 Linux RT 调度器rt_bandwidth带宽控制机制，核心要点总结：

1. rt_bandwidth依托CONFIG_RT_GROUP_SCHED实现 RT 任务组级带宽限流，通过rt_period_us+rt_runtime_us双参数精准控制 CPU 占用率；
2. 内核通过高精度定时器做周期配额重置，实时统计组内 RT 任务运行时长，超出阈值自动触发节流调度；
3. 用户态无需开发复杂程序，直接操作 cgroup cpu 子系统接口即可完成配置，落地成本极低。

rt_bandwidth 机制是 Linux 实时系统稳定性保障的核心能力，除前文提到的工业控制、自动驾驶、多租户容器云场景外，还可应用于实时数据库交易调度、音视频实时编解码、航天嵌入式实时服务器、机器人控制系统等领域。

对于内核开发者，可基于本文源码逻辑二次开发，定制差异化 RT 带宽限流策略；对于运维与架构工程师，可直接复用本文配置步骤与最佳实践，落地生产环境 RT 业务资源隔离；对于高校学生与科研人员，本文的源码解析、实操命令、调试方法可直接用于 Linux 调度子系统论文撰写、课题调研。建议读者在真机环境复现所有命令与代码，结合内核源码逐行跟踪调用流程，真正吃透 RT 任务组带宽控制的底层本质。