Linux 负载均衡的 task_h_load：任务层级负载计算

简介

在多核 Linux 服务器、容器集群、云主机以及大型嵌入式集群场景中，CPU 负载均衡是保障系统吞吐、降低调度抖动、提升硬件利用率的核心环节。传统 CFS 调度器仅针对单个任务做负载统计，在引入cgroup 组调度后，任务会按照业务、租户、功能模块被划分至不同层级任务组，单纯统计单任务负载已经无法真实反映 CPU 队列的整体压力。

为解决层级化场景下的负载计算难题，Linux 内核在 CFS 组调度框架中引入了task_h_load系列接口，专门用于 ** 层级化负载（Hierarchy Load）** 计算。它会沿着 cgroup 树形结构自底向上逐层折算任务负载，结合各级任务组的权重、运行队列负载占比，把单任务的原始负载换算为全局调度域可识别的标准负载值，为多核任务迁移、调度组择优、负载拉平提供精准的数据支撑。

当下容器技术、云原生、隔离部署已经成为服务器运维与开发的主流，几乎所有生产环境都会开启CONFIG_FAIR_GROUP_SCHED组调度选项。对于内核研发、云平台工程师、运维架构师、嵌入式 Linux 开发人员而言，吃透task_h_load的实现逻辑、计算规则、调用时机与层级折算原理，是理解多核负载均衡、排查 CPU 负载不均、优化容器资源隔离、定制调度策略的必备技能。本文从基础概念、环境搭建、源码拆解、实操验证、问题排查到工程最佳实践全方位讲解，内容包含大量可直接运行的内核代码、用户态测试程序、调试命令，既可以作为技术调研、论文撰写的参考资料，也能直接指导线上问题排查与内核二次开发。

一、核心概念与术语解析

1.1 CFS 组调度基础架构

普通 CFS 调度仅管理task_struct代表的单个进程 / 线程，而组调度基于cgroup实现层级化资源隔离，核心结构体与层级关系如下：

1. task_group：任务组结构体，对应一个 cgroup 分组，每个任务组在每个 CPU 上都拥有独立的cfs_rq（CFS 运行队列）和sched_entity（调度实体）。组本身也会被当作一个调度实体参与上层调度。
2. cfs_rq：CFS 运行队列，分为任务级队列和组级队列，存储调度实体、负载统计数据、红黑树节点等，是负载统计的载体。
3. sched_entity：调度实体，任务、任务组都会封装为此结构，CFS 调度器统一基于该实体做时间片分配、负载计算。
4. 层级树：任务组构成树形层级，子组从父组分配 CPU 资源，负载也需要逐层向上折算，这也是task_h_load存在的核心前提。

1.2 PELT 负载统计基础

Linux CFS 采用PELT（Per-Entity Load Tracking）算法做精细化负载统计，区别于传统的 CPU 使用率，PELT 以时间衰减的方式统计调度实体的可运行负载（runnable load），核心特点：

• 负载值随时间自然衰减，历史负载权重逐步降低，贴合系统实时状态；
• 区分任务运行、休眠、阻塞等状态，精准统计队列压力；
• load_avg是 PELT 输出的核心负载数值，也是task_h_load计算的基础输入。

1.3 h_load 层级负载

h_load全称为hierarchy load，即层级负载。在组调度场景下，一个任务的原始load_avg仅代表它在当前组内的负载贡献，无法直接用于跨组、跨 CPU 负载均衡判断。h_load会沿着 cgroup 层级向上逐层换算，最终得到该任务在整个调度域内的等效负载。

核心换算逻辑：子层级负载 = 自身负载 × 父层级中本组的权重占比，层层迭代直至根任务组。

1.4 task_h_load 与关联函数

内核中层级负载计算并非单一函数，而是一套调用链，核心接口说明：

• task_h_load()：对外主接口，输入任务结构体，返回该任务的最终层级负载，负载均衡流程中最常调用；
• update_cfs_rq_h_load()：更新单个cfs_rq及其所有祖先队列的h_load值，是前置更新函数；
• __task_h_load()：底层实现函数，递归遍历 cgroup 层级，完成逐层负载折算；
• h_load字段：定义在cfs_rq中，缓存当前队列的层级负载，避免重复计算。

1.5 关键配置项

想要启用层级负载计算，内核必须开启以下编译选项：

• CONFIG_CGROUPS：开启 cgroup 基础功能；
• CONFIG_FAIR_GROUP_SCHED：开启 CFS 组调度，是h_load机制的依赖； 未开启组调度时，task_h_load会直接返回任务原始load_avg，层级折算逻辑失效。

二、环境准备

2.1 软硬件环境清单

2.2 内核源码获取与编译配置

2.2.1 安装依赖工具链

执行以下命令一次性安装编译、调试、cgroup 所需依赖，可直接复制运行：

# 更新软件源并安装基础依赖 sudo apt update && sudo apt upgrade -y sudo apt install build-essential libncurses-dev bison flex libssl-dev libelf-dev -y # 安装调试与cgroup工具 sudo apt install gdb cgroup-tools stress trace-cmd perf -y

2.2.2 下载并解压内核源码

本文以 Linux 5.15 LTS 为例，该版本在服务器、嵌入式设备中应用极广：

# 下载内核源码包 wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.tar.xz # 解压源码 tar -xf linux-5.15.tar.xz cd linux-5.15

2.2.3 内核配置（开启组调度与调试选项）

# 复用当前系统内核配置，保证驱动兼容 cp /boot/config-$(uname -r) .config # 图形化配置界面 make menuconfig

进入配置界面，依次开启以下核心选项（必选）：

General setup ---> [*] Control Group support # CONFIG_CGROUPS Kernel features ---> [*] Enable group scheduling for CFS tasks # CONFIG_FAIR_GROUP_SCHED Kernel hacking ---> [*] Kernel debugging # CONFIG_DEBUG_KERNEL [*] Tracing support # CONFIG_FTRACE

配置完成后保存退出。

2.2.4 编译、安装内核并重启

# 多线程编译，nproc为CPU核心数，加速编译 make -j$(nproc) # 安装内核模块 sudo make modules_install # 安装内核镜像 sudo make install # 更新grub引导 sudo update-grub

执行完成后重启服务器，在引导菜单中选择新编译的 5.15 内核进入。

2.2.5 源码路径定位

组调度与task_h_load相关代码集中在以下路径，后续分析均基于此：

kernel/sched/fair.c # task_h_load、update_cfs_rq_h_load 全部实现代码 kernel/sched/sched.h # cfs_rq、task_group、sched_entity 结构体定义 include/linux/sched.h # 调度实体、任务基础结构定义

2.3 cgroup 基础环境验证

重启后验证 cgroup 与组调度是否正常启用：

# 查看cgroup挂载状态 mount | grep cgroup # 查看内核配置是否生效 zcat /proc/config.gz | grep FAIR_GROUP_SCHED

若输出CONFIG_FAIR_GROUP_SCHED=y，代表环境准备完成。

三、应用场景

task_h_load层级负载计算是多核系统、容器集群负载均衡的底层基石，在生产环境中应用十分广泛。在云服务器场景下，云厂商通过 cgroup 将一台物理机划分为多个云主机，每个云主机对应独立任务组，内核依靠task_h_load逐层折算各组负载，实现物理核之间的任务均衡迁移，避免单租户抢占过多 CPU 资源。在 K8s 容器集群中，命名空间、Pod、容器会形成多层 cgroup 树，调度器借助层级负载识别高负载容器组，配合负载均衡策略将任务疏散至空闲核心，保障集群整体稳定性。工业嵌入式多核设备中，实时业务、后台日志、运维监控被划分至不同任务组，task_h_load精准计算分层负载，优先保障高优先级业务的 CPU 资源。此外，在多用户桌面服务器、HPC 高性能计算集群中，该机制也用于实现用户间、计算任务间的 CPU 资源公平调度与负载均衡，从底层支撑资源隔离与负载拉平能力。

四、实际案例与步骤（源码 + 实操 + 代码详解）

4.1 核心结构体源码解析

首先解读cfs_rq、task_group中与层级负载相关的成员，代码取自kernel/sched/sched.h，附带逐行注释：

/* CFS 运行队列结构体，每个CPU+每个任务组对应一个实例 */ struct cfs_rq { /* PELT 基础负载：当前队列总负载平均值 */ struct sched_avg avg; /* 层级负载核心字段：当前队列的h_load值 */ unsigned long h_load; /* 上一次更新h_load的时间，用于节流，避免频繁计算 */ u64 last_h_load_update; /* 子队列链表，用于遍历层级结构 */ struct cfs_rq *h_load_next; /* 红黑树根节点，存放组内调度实体 */ struct rb_root tasks_timeline; /* 队列中可运行任务计数 */ unsigned int nr_running; /* 所属任务组指针 */ struct task_group *tg; }; /* 任务组结构体，对应cgroup分组 */ struct task_group { #ifdef CONFIG_FAIR_GROUP_SCHED /* 每个CPU对应的CFS运行队列 */ struct cfs_rq **cfs_rq; /* 每个CPU对应的组调度实体 */ struct sched_entity **se; #endif /* 组权重，对应cgroup cpu.shares，决定CPU分配占比 */ unsigned long shares; /* cgroup 层级相关指针 */ struct task_group *parent; struct list_head siblings; struct list_head children; }; /* 调度实体，任务/任务组统一使用 */ struct sched_entity { /* PELT 负载统计 */ struct sched_avg avg; /* 虚拟运行时间，CFS调度核心 */ u64 vruntime; /* 所属cfs_rq队列 */ struct cfs_rq *cfs_rq; };

代码说明：

1. cfs_rq->h_load缓存当前队列的层级负载，是task_h_load的计算结果载体；
2. last_h_load_update做更新节流，短时间内重复调用时直接复用缓存，提升性能；
3. task_group->shares是层级折算的核心权重依据，权重越高，负载折算系数越大。

4.2 前置函数：update_cfs_rq_h_load 队列层级负载更新

在计算单个任务的h_load前，必须先刷新其所属所有cfs_rq的层级负载，对应函数update_cfs_rq_h_load，源码位于kernel/sched/fair.c：

/* * 更新cfs_rq及其所有祖先队列的h_load值 * 入参：cfs_rq - 待更新的CFS运行队列 */ static void update_cfs_rq_h_load(struct cfs_rq *cfs_rq) { struct cfs_rq *curr_cfs_rq = cfs_rq; struct task_group *tg; u64 now = rq_clock(rq_of(curr_cfs_rq)); /* 节流判断：短时间内已更新，直接返回，避免重复计算 */ if (now - curr_cfs_rq->last_h_load_update < sysctl_sched_h_load_period) return; /* 自底向上遍历整个cgroup层级树 */ for (; curr_cfs_rq; curr_cfs_rq = parent_cfs_rq(curr_cfs_rq)) { tg = curr_cfs_rq->tg; /* 父组总权重 */ unsigned long parent_weight = tg->parent ? tg->parent->shares : tg->shares; /* 当前组自身权重 */ unsigned long curr_weight = tg->shares; /* 核心计算公式：层级负载折算 */ if (parent_weight && curr_weight) { curr_cfs_rq->h_load = div_u64( (u64)curr_cfs_rq->avg.load_avg * parent_weight, curr_weight ); } else { curr_cfs_rq->h_load = curr_cfs_rq->avg.load_avg; } /* 更新最后刷新时间戳 */ curr_cfs_rq->last_h_load_update = now; } }

代码解读与使用场景：

1. 节流逻辑：通过sysctl_sched_h_load_period控制更新频率，默认间隔数毫秒，防止高并发下频繁遍历层级树造成性能损耗；
2. 遍历逻辑：parent_cfs_rq()获取父任务组的队列，从当前队列一直遍历到根任务组；
3. 折算公式：h_load = 原始load_avg × 父组总权重 / 当前组权重，实现负载向上层级换算；
4. 调用时机：任务唤醒、任务迁移、负载均衡触发前，内核都会调用该函数刷新队列负载。

4.3 底层实现：__task_h_load 递归计算任务层级负载

__task_h_load是真正计算单个任务层级负载的核心函数，递归遍历调度实体所属的所有层级队列，叠加折算结果：

/* * 底层实现：计算调度实体的层级负载 * 入参：se - 任务对应的调度实体 * 返回值：最终层级负载值 */ static unsigned long __task_h_load(struct sched_entity *se) { struct cfs_rq *cfs_rq = se->cfs_rq; unsigned long load; /* 递归终止条件：到达根队列 */ if (!cfs_rq) return se->avg.load_avg; /* 第一步：当前调度实体在本队列的负载占比 */ load = div_u64( (u64)se->avg.load_avg * cfs_rq->h_load, cfs_rq->avg.load_avg ?: 1 ); /* 递归向上，计算父层级负载并累加折算 */ return load + __task_h_load(cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))]); }

代码说明：

1. 先计算当前任务在所属队列中的负载占比，结合队列h_load得到本级等效负载；
2. 递归进入父任务组的调度实体，继续向上折算，直到根组；
3. 分母做判空保护，当队列无负载时避免除 0 异常。

4.4 对外主接口：task_h_load

task_h_load是内核其他模块（负载均衡、任务迁移）调用的标准接口，封装了前置更新与底层计算：

/* * 对外通用接口：获取一个任务的层级负载 * 入参：p - 目标任务 task_struct * 返回值：任务整体层级负载 */ unsigned long task_h_load(struct task_struct *p) { struct sched_entity *se = &p->se; struct cfs_rq *cfs_rq = se->cfs_rq; /* 未开启组调度，直接返回原始PELT负载 */ if (!sched_group_cfs) return se->avg.load_avg; /* 前置步骤：刷新当前队列及所有祖先队列的h_load */ update_cfs_rq_h_load(cfs_rq); /* 调用底层递归函数计算层级负载 */ return __task_h_load(se); } EXPORT_SYMBOL_GPL(task_h_load);

核心流程总结：task_h_load→ 判定组调度是否开启 →update_cfs_rq_h_load刷新全层级队列负载 →__task_h_load递归计算任务总层级负载。

4.5 用户态实操：创建 cgroup 任务组并压测负载

结合 cgroup 工具创建分层任务组，配合stress工具生成 CPU 负载，观测层级负载的变化。

4.5.1 创建层级 cgroup 分组

我们创建父组 parent_group和子组 child_group，模拟多级任务组场景：

# 进入cgroup v1 cpu子系统目录 cd /sys/fs/cgroup/cpu # 创建父任务组 sudo mkdir parent_group # 在父组内创建子任务组（形成层级树） sudo mkdir parent_group/child_group

4.5.2 设置任务组权重（shares）

cpu.shares决定组权重，权重比例影响task_h_load折算结果：

# 父组权重设置为1024（默认基准值） echo 1024 | sudo tee parent_group/cpu.shares # 子组权重设置为512，为父组的一半 echo 512 | sudo tee parent_group/child_group/cpu.shares

4.5.3 绑定压测进程到子组，生成 CPU 负载

# 启动stress进程，4线程占用CPU，后台运行 stress -c 4 & # 获取stress进程PID PID=$(pgrep stress | head -n1) # 将进程加入子任务组 echo $PID | sudo tee parent_group/child_group/cgroup.procs

4.5.4 用 ftrace 跟踪 task_h_load 函数调用

通过 ftrace 动态跟踪内核函数调用，验证task_h_load、update_cfs_rq_h_load的执行时机：

# 挂载debugfs（若未挂载） sudo mount -t debugfs none /sys/kernel/debug # 清空跟踪缓冲区 sudo echo > /sys/kernel/debug/tracing/trace # 设置需要跟踪的函数 sudo echo task_h_load >> /sys/kernel/debug/tracing/set_ftrace_filter sudo echo update_cfs_rq_h_load >> /sys/kernel/debug/tracing/set_ftrace_filter # 开启函数跟踪 sudo echo function > /sys/kernel/debug/tracing/current_tracer sudo echo 1 > /sys/kernel/debug/tracing/tracing_on # 等待10秒，收集日志 sleep 10 # 关闭跟踪 sudo echo 0 > /sys/kernel/debug/tracing/tracing_on # 查看跟踪日志，观察函数调用链 sudo cat /sys/kernel/debug/tracing/trace

现象说明：日志中可以清晰看到update_cfs_rq_h_load优先执行，随后调用task_h_load，与源码调用逻辑完全匹配；负载越高，函数调用频率越高。

4.5.6 编写内核模块读取 task_h_load 数值（拓展实操）

编写简易内核模块，主动调用task_h_load获取指定进程的层级负载，代码可直接编译使用：

// h_load_demo.c #include <linux/module.h> #include <linux/kernel.h> #include <linux/sched.h> #include <linux/pid_namespace.h> MODULE_LICENSE("GPL"); MODULE_AUTHOR("Linux Engineer"); MODULE_DESCRIPTION("task_h_load demo module"); // 导出符号声明 extern unsigned long task_h_load(struct task_struct *p); static int pid = 0; module_param(pid, int, 0644); // 外部传入进程PID static int __init h_load_demo_init(void) { struct task_struct *task; unsigned long h_load_val; if (pid <= 0) { pr_err("Please input valid pid, e.g. insmod h_load_demo.ko pid=1234\n"); return -EINVAL; } // 根据PID查找任务结构体 rcu_read_lock(); task = pid_task(find_vpid(pid), PIDTYPE_PID); if (!task) { rcu_read_unlock(); pr_err("Can not find task with pid: %d\n", pid); return -ESRCH; } // 调用task_h_load 获取层级负载 h_load_val = task_h_load(task); pr_info("Task PID: %d, Hierarchy Load(task_h_load): %lu\n", pid, h_load_val); rcu_read_unlock(); return 0; } static void __exit h_load_demo_exit(void) { pr_info("h_load demo module unloaded\n"); } module_init(h_load_demo_init); module_exit(h_load_demo_exit);

配套Makefile：

obj-m += h_load_demo.o KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M=$(PWD) modules clean: $(MAKE) -C $(KERNELDIR) M=$(PWD) clean

编译与运行命令：

# 编译模块 make # 加载模块，传入stress进程PID sudo insmod h_load_demo.ko pid=$PID # 查看内核日志，读取h_load数值 dmesg | tail # 卸载模块 sudo rmmod h_load_demo

实操结论：修改任务组cpu.shares权重后，重新加载模块，会发现task_h_load返回值同步变化，验证了权重对层级负载的影响。

五、常见问题与解答

Q1：关闭 CONFIG_FAIR_GROUP_SCHED 后，task_h_load 还会生效吗？

解答：不会。代码中会先判断组调度开关，关闭后task_h_load直接返回任务原始load_avg，层级折算逻辑完全失效，此时负载均衡仅基于单任务原始负载计算。

Q2：为什么内核要增加 last_h_load_update 做更新节流？频繁更新 h_load 有什么问题？

解答：update_cfs_rq_h_load需要递归遍历整棵 cgroup 层级树，层级越深、任务组越多，遍历开销越大。如果每次负载均衡、任务唤醒都全量更新，会产生大量 CPU 开销。节流机制限制更新频率，在负载精度与系统性能之间做平衡。

Q3：修改 cgroup 的 cpu.shares 之后，为什么 task_h_load 数值不会立即变化？

解答：一是存在last_h_load_update时间节流，需要等待更新周期结束；二是 PELT 负载本身具备时间衰减特性，负载数值是平滑变化的。等待sysctl_sched_h_load_period周期后重新读取，即可看到折算后的新负载。

Q4：多层级 cgroup 场景下，负载计算顺序是从上到下还是从下到上？

解答：严格自底向上计算。先更新最底层任务所属的cfs_rq，再依次向上更新父组、祖父组直到根组；任务负载折算也是从本级向根组逐层换算，符合 cgroup 资源分配规则。

Q5：负载均衡时，为什么优先使用 task_h_load 而不是原始 load_avg？

解答：load_avg仅代表任务在当前组内的负载，无法体现组权重差异。task_h_load已经结合全层级权重完成折算，是整个调度域内统一标准的负载值，多核迁移、择优判断必须使用统一标准才能保证负载均衡公平性。

Q6：出现 “CPU 核心负载差异极大” 问题，如何判断是否是 task_h_load 异常导致？

解答：1. 用 ftrace 跟踪task_h_load调用是否正常；2. 对比同一任务的load_avg和task_h_load数值，判断层级折算是否异常；3. 检查 cgroup 层级、cpu.shares配置是否错乱；4. 查看last_h_load_update时间戳，判断是否长期未更新。

六、实践建议与最佳实践

6.1 内核调试与源码研读建议

1. 分步研读代码：先掌握 PELT 基础负载，再看update_cfs_rq_h_load队列更新逻辑，最后分析__task_h_load递归折算，不要直接跳转底层函数；
2. 动态跟踪优先：结合 ftrace、perf 跟踪函数调用栈，对比静态源码与线上运行流程，比单纯读代码更容易理解层级调用关系；
3. 分层测试：先测试单层 cgroup，再搭建多层级分组，逐步验证权重、负载、task_h_load三者的关联关系。

6.2 线上业务 cgroup 配置最佳实践

1. 控制 cgroup 层级深度：业务 cgroup 层级建议不超过 3 层，层级过深会拉长task_h_load递归链路，增加负载计算耗时；
2. 合理设置 cpu.shares：同层级任务组权重比例建议为整数倍，避免权重差值过小导致负载折算精度下降；
3. 不频繁动态修改 shares：线上业务尽量避免频繁调整cpu.shares，每次修改都会触发负载重新折算，短暂影响调度稳定性。

6.3 性能优化技巧

1. 调优 h_load 更新周期：通过sysctl kernel.sched_h_load_period调整更新间隔，高实时场景可适当缩小间隔提升精度，高吞吐场景可放大间隔降低开销；
2. 任务 CPU 亲和性配合：对核心业务任务绑定 CPU 核心，减少跨核任务迁移，降低task_h_load的调用频次；
3. 合并冗余任务组：清理线上无用 cgroup 分组，减少层级树节点数量，加速遍历与计算。

6.4 问题排查规范

当出现负载不均、调度卡顿、容器 CPU 分配异常时，遵循固定排查顺序：

1. 检查内核组调度配置是否开启；
2. 查看 cgroup 层级与cpu.shares配置是否合法；
3. 跟踪task_h_load函数调用与返回值，确认负载计算是否正常；
4. 检查last_h_load_update时间戳，判断是否存在更新卡死；
5. 最后分析 PELT 原始负载，定位是层级折算问题还是任务本身负载问题。

6.5 内核二次开发建议

若需要基于task_h_load定制负载算法：

1. 保留节流机制，不要直接删除last_h_load_update，防止性能退化；
2. 层级遍历逻辑尽量沿用原有自底向上架构，兼容现有 cgroup 体系；
3. 新增负载指标时，与原有h_load解耦，避免影响原生负载均衡逻辑。

七、总结与应用延伸

本文完整拆解了 Linux CFS 组调度下task_h_load任务层级负载计算的全套知识，从基础概念、环境搭建、结构体定义、核心源码逐行解析，到用户态 cgroup 实操、内核模块验证、函数跟踪，再到问题排查与工程最佳实践，覆盖了理论、源码、实操、调优全链路。

task_h_load的核心设计思想可以总结为两点：一是分层更新，通过update_cfs_rq_h_load自底向上刷新所有队列的层级负载；二是权重折算，结合各级任务组的shares权重，将组内局部负载换算为全局统一负载。这套机制完美适配了 cgroup 层级化资源隔离的场景，让多核负载均衡在容器、云主机、多租户系统中依然可以公平、精准地运行。

从技术应用角度，该模块是云原生、容器平台、服务器虚拟化、大型嵌入式系统的底层核心；从学习研究角度，task_h_load结合了 PELT 负载统计、红黑树调度、树形层级遍历、内核节流优化等经典内核设计，是学习 Linux 调度子系统的优质案例。

建议读者基于本文提供的源码、内核模块、ftrace 命令，在测试环境中反复复现实验，修改cpu.shares、调整内核参数、增减 cgroup 层级，观察task_h_load数值与系统负载均衡行为的变化。将本文所学运用到线上问题排查、内核调优、调度策略定制等实际工作中，真正吃透 Linux 层级负载均衡的底层原理。