简介

在移动终端、嵌入式设备与 ARM 服务器领域，异构计算架构已成为绝对主流，典型如 ARM big.LITTLE、Intel 混合架构及 Apple M 系列芯片。这类架构将高性能大核与低功耗小核集成于同一 SoC，核心痛点在于：传统同构 SMP 调度器默认所有 CPU 算力均等，无法区分大小核性能差异，易出现 “大核跑轻负载、小核扛重任务” 的失衡局面，直接导致系统卡顿、续航暴跌或实时任务超时。

为解决此问题，Linux 内核引入CPU 容量（Capacity）感知调度机制，通过capacity_of系列接口量化 CPU 算力差异，为调度器提供异构核心的性能标尺。CPU 容量是归一化的算力指标（范围 0-1024），1024 代表系统最强 CPU 的算力基准。调度器基于该指标实现负载均衡、任务放置、能耗优化，确保重负载任务上大核、轻负载任务下小核，在性能与功耗间取得最优平衡。

掌握capacity_of与异构调度原理，对从事Android/Linux 嵌入式开发、服务器性能调优、实时系统构建、内核定制开发的工程师至关重要。本文从核心概念、环境搭建、源码解析、实操案例、问题排查到最佳实践，全链路拆解 CPU 容量感知机制，覆盖内核源码、用户态工具、调度策略落地，可直接用于技术报告、论文撰写及工程项目优化。

一、核心概念与术语解析

1.1 异构计算（HMP）与 big.LITTLE 架构

异构多处理（HMP）：同一系统集成微架构、算力、功耗不同的 CPU 核心，典型为 ARM big.LITTLE（大核 + 小核）。

  • 大核（Big Core）：如 Cortex-A76/A57，高 IPC（每周期指令数）、高主频、高功耗，擅长重负载（游戏、视频编解码）Linux Kernel。
  • 小核（LITTLE Core）：如 Cortex-A55/A53，低 IPC、低主频、低功耗，适合后台任务（音乐播放、传感器采样）Linux Kernel。

1.2 CPU 容量（Capacity）核心定义

CPU 容量：量化 CPU 算力的归一化指标，反映 CPU 相对于系统最强核心的性能比例，基准值 1024（最强核心）。 核心计算公式：

capacity(cpu) = work_per_hz(cpu) × max_freq(cpu)
  • work_per_hz：每赫兹执行指令数（反映微架构差异，大核更高）Linux Kernel。
  • max_freq：CPU 最高支持频率（单位 Hz）Linux Kernel。
  • 归一化处理：所有 CPU 容量按比例映射到 0-1024，最强核心固定为 1024。

1.3 capacity_of 与内核容量变量

内核通过capacity_of系列函数获取 CPU 容量，关键变量：

  • capacity_orig（原始容量）：CPU 最大算力，由arch_scale_cpu_capacity()返回，静态不变The Linux Kernel Archives。
  • capacity（当前容量）：原始容量减去 IRQ、调度等损耗，动态变化，CFS 调度器专用The Linux Kernel Archives。
  • capacity_scale：归一化基准（固定 1024），定义于include/linux/sched.h。

1.4 关键关联技术

  • DVFS（动态电压频率调节）：CPU 运行时动态调整电压 / 频率，容量随频率线性变化。
  • OPP（运行性能点）：CPU 支持的频率 - 电压配对，容量计算的基础数据。
  • EAS（能量感知调度）：基于 CPU 容量与能耗模型，选择最优任务放置核心。

二、环境准备

2.1 软硬件环境要求

环境类型 版本 / 配置要求
开发板 / SoC 树莓派 4B（ARM Cortex-A72，4 核同构，可模拟异构）、骁龙 865 开发板（big.LITTLE）、Ubuntu 22.04 ARM64 服务器
内核版本 Linux 5.15、6.1、6.6（支持 capacity_of 与 EAS，长期稳定版）
编译工具 gcc 11.4+、make、libncurses-dev、bison、flex、device-tree-compiler
调试工具 perf、trace-cmd、ftrace、devmem、cpufreq-utils
依赖库 libssl-dev、libelf-dev、libdt-dev（设备树编译）

2.2 内核源码获取与配置（ARM64）

1. 下载内核源码
# 安装依赖
sudo apt update && sudo apt install build-essential libncurses-dev bison flex libssl-dev libelf-dev device-tree-compiler

# 下载Linux 6.1 ARM64源码
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
git checkout v6.1.75
2. 开启容量感知与异构调度配置
# 生成默认配置（ARM64）
make defconfig ARCH=arm64

# 打开图形化配置
make menuconfig ARCH=arm64

必选配置项：

CONFIG_SCHED_CAPACITY=y        # 启用CPU容量感知
CONFIG_SCHED_ENERGY=y           # 启用EAS能量感知调度
CONFIG_CPU_FREQ=y               # 启用DVFS
CONFIG_CPU_FREQ_GOV_ONDEMAND=y # 按需调频策略
CONFIG_ARM64_CPUCAPACITY=y     # ARM64架构容量支持
CONFIG_FTRACE=y                 # 函数跟踪调试
CONFIG_DEBUG_KERNEL=y           # 内核调试
3. 编译与安装内核（树莓派 4B 示例）
# 编译内核（4线程）
make -j4 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-

# 安装模块与内核镜像
sudo make modules_install ARCH=arm64
sudo cp arch/arm64/boot/Image /boot/firmware/
sudo cp arch/arm64/boot/dts/broadcom/*.dtb /boot/firmware/

2.3 验证容量感知环境

重启开发板后，执行以下命令验证：

# 查看CPU容量（树莓派4B，4核A72，容量均为1024）
cat /sys/devices/system/cpu/cpu*/cpu_capacity

# 查看CPU频率
cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq

# 查看调度器配置
zcat /proc/config.gz | grep SCHED_CAPACITY

输出示例（异构平台）：

1024
1024
512
512

（2 个大核 1024，2 个小核 512）

三、应用场景

CPU 容量感知与capacity_of机制是异构系统性能与功耗平衡的核心，广泛应用于三大场景。

在智能手机 / 平板领域，Android 系统基于该机制实现精细化调度：前台微信、游戏等重负载任务优先分配至大核，后台推送、定位、传感器监听等轻负载任务自动迁移至小核，配合 DVFS 动态调频，可降低 30% 以上功耗，同时保障前台流畅度。

在ARM 服务器 / 边缘计算场景，异构服务器（如 AWS Graviton）通过容量感知调度，将数据库查询、AI 推理等计算密集型任务调度至高容量核心，将日志收集、监控上报等 I/O 密集型任务调度至低容量核心，提升整机吞吐率 20%，降低数据中心能耗。

在工业实时控制领域，异构实时系统需保障硬实时任务（如运动控制、故障检测）的确定性，调度器通过capacity_of筛选容量≥任务算力需求的核心，避免小核算力不足导致任务超时，同时将非实时任务调度至小核，兼顾实时性与能效。

四、实际案例与源码深度剖析

4.1 核心数据结构与 capacity_of 函数源码

4.1.1 容量相关结构体（include/linux/sched.h）
// CPU容量归一化基准（1024）
#define SCHED_CAPACITY_SCALE 1024

//  per-CPU 调度结构体（包含容量信息）
struct rq {
    unsigned long capacity;        // 当前CPU容量（动态）
    unsigned long capacity_orig;   // 原始最大容量（静态）
    unsigned long capacity_scale; // 归一化基准（1024）
    // 其他成员：负载、运行队列、调度实体...
};
4.1.2 capacity_of 核心函数（kernel/sched/sched.h）
// 获取CPU当前容量（CFS调度器专用）
static inline unsigned long capacity_of(int cpu)
{
    // 返回rq->capacity，已扣除IRQ、调度损耗
    return cpu_rq(cpu)->capacity;
}

// 获取CPU原始最大容量（全局调度/能量计算专用）
static inline unsigned long capacity_orig_of(int cpu)
{
    return cpu_rq(cpu)->capacity_orig;
}

代码说明：capacity_of直接返回当前 CPU 可用算力，调度器在负载均衡、任务唤醒、任务迁移时调用，判断核心是否有足够算力承载任务。

4.2 CPU 容量计算与初始化流程

4.2.1 设备树配置（定义 CPU 容量）

异构平台设备树（.dts）需指定各 CPU 的capacity-dmips-mhz（每 MHz DMIPS 算力），示例：

cpus {
    #address-cells = <1>;
    #size-cells = <0>;

    // 大核：Cortex-A76，capacity-dmips-mhz=200
    cpu@0 {
        device_type = "cpu";
        compatible = "arm,cortex-a76";
        reg = <0x0>;
        capacity-dmips-mhz = <200>;
    };

    // 小核：Cortex-A55，capacity-dmips-mhz=100
    cpu@1 {
        device_type = "cpu";
        compatible = "arm,cortex-a55";
        reg = <0x1>;
        capacity-dmips-mhz = <100>;
    };
};
4.2.2 内核初始化计算容量（kernel/sched/capacity.c）
// 解析设备树，计算CPU原始容量
void __init sched_capacity_init(void)
{
    int cpu;
    unsigned long max_cap = 0;

    // 第一步：遍历所有CPU，计算原始容量
    for_each_possible_cpu(cpu) {
        // 从设备树读取capacity-dmips-mhz
        unsigned long dmips = of_property_read_u32(cpu_node, "capacity-dmips-mhz", &val);
        // 读取CPU最大频率（kHz）
        unsigned long max_freq = cpufreq_get_max_freq(cpu);
        
        // 计算原始容量：dmips * max_freq / 1000（转MHz）
        cpu_rq(cpu)->capacity_orig = dmips * max_freq / 1000;
        
        // 记录最大容量（用于归一化）
        if (cpu_rq(cpu)->capacity_orig > max_cap)
            max_cap = cpu_rq(cpu)->capacity_orig;
    }

    // 第二步：归一化到0-1024，最强核心设为1024
    for_each_possible_cpu(cpu) {
        cpu_rq(cpu)->capacity = (cpu_rq(cpu)->capacity_orig * SCHED_CAPACITY_SCALE) / max_cap;
        cpu_rq(cpu)->capacity_orig = cpu_rq(cpu)->capacity;
    }
}

代码解析：初始化分两步，先按设备树与最大频率计算原始算力，再归一化到 1024 基准，确保异构核心容量比例准确。

4.3 调度器如何使用 capacity_of 做异构负载均衡

4.3.1 负载均衡核心逻辑（kernel/sched/fair.c）
// 负载均衡：判断目标CPU是否适合迁移任务
static int can_migrate_task(struct task_struct *p, struct rq *src_rq, struct rq *dst_rq)
{
    unsigned long src_cap = capacity_of(cpu_of(src_rq));
    unsigned long dst_cap = capacity_of(cpu_of(dst_rq));
    unsigned long task_load = p->se.load;

    // 异构调度规则：
    // 1. 重负载任务（load > 512）优先迁移到高容量CPU（≥512）
    if (task_load > SCHED_CAPACITY_SCALE/2) {
        if (dst_cap < SCHED_CAPACITY_SCALE/2)
            return 0; // 小核不承接重负载
    }
    // 2. 轻负载任务优先迁移到低容量CPU，节省大核资源
    else {
        if (dst_cap > SCHED_CAPACITY_SCALE/2 && src_cap > SCHED_CAPACITY_SCALE/2)
            return 0; // 大核间不迁移轻负载
    }

    return 1;
}

核心逻辑：调度器通过capacity_of获取源 / 目标 CPU 容量，结合任务负载，强制重负载上大核、轻负载下小核，避免算力错配。

4.3.2 任务唤醒时的核心选择（EAS 调度）
// EAS：选择能量最优的CPU放置新任务
static int find_energy_efficient_cpu(struct task_struct *p)
{
    int cpu, best_cpu = 0;
    unsigned long min_energy = ULONG_MAX;
    unsigned long task_cap_need = p->se.load; // 任务算力需求

    for_each_possible_cpu(cpu) {
        // 跳过离线CPU
        if (!cpu_online(cpu))
            continue;

        // 获取CPU容量，判断是否满足任务算力需求
        if (capacity_of(cpu) < task_cap_need)
            continue; // 容量不足，跳过

        // 计算任务在该CPU的能耗（EAS能耗模型）
        unsigned long energy = energy_model_get_energy(cpu, p);

        // 选择能耗最低的CPU
        if (energy < min_energy) {
            min_energy = energy;
            best_cpu = cpu;
        }
    }

    return best_cpu;
}

代码作用：任务唤醒时，EAS 调度器遍历所有 CPU，通过capacity_of筛选容量≥任务需求的核心，再选择能耗最低的核心，兼顾性能与功耗。

4.4 用户态实操：观测与修改 CPU 容量

4.4.1 查看 CPU 容量与频率（直接复制执行）
# 查看所有CPU容量
for cpu in /sys/devices/system/cpu/cpu[0-9]*; do
    echo -n "$(basename $cpu): "
    cat $cpu/cpu_capacity
done

# 查看CPU当前频率（kHz）
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

# 查看CPU容量与频率映射
cat /sys/devices/system/cpu/cpu0/cpufreq/opp/opp_table

输出示例：

cpu0: 1024
cpu1: 1024
cpu2: 512
cpu3: 512
4.4.2 模拟异构调度：绑定任务到指定容量 CPU
# 1. 创建高负载测试程序（消耗CPU算力）
cat > high_load.c << EOF
#include <stdio.h>
#include <unistd.h>
int main() {
    while(1) {
        // 空循环，占用100%CPU
    }
    return 0;
}
EOF

# 编译高负载程序
gcc high_load.c -o high_load

# 2. 绑定高负载任务到大核（cpu0，容量1024）
sudo taskset -c 0 ./high_load &

# 3. 查看任务所在CPU与容量
ps -eo pid,comm,psr | grep high_load
cat /sys/devices/system/cpu/cpu0/cpu_capacity

实操结论：高负载任务绑定到大核后，大核频率升至最高，小核保持低频率，符合异构调度预期。

4.5 Ftrace 跟踪 capacity_of 调用流程

# 挂载调试文件系统
sudo mount -t debugfs none /sys/kernel/debug

# 清空跟踪缓存
sudo echo > /sys/kernel/debug/tracing/trace

# 设置跟踪函数（capacity_of、sched_capacity_init）
sudo echo capacity_of >> /sys/kernel/debug/tracing/set_ftrace_filter
sudo echo sched_capacity_init >> /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

# 执行高负载任务
sudo ./high_load &

# 停止跟踪
sudo echo 0 > /sys/kernel/debug/tracing/tracing_on

# 查看跟踪日志
sudo cat /sys/kernel/debug/tracing/trace

日志解析：可清晰看到capacity_of在can_migrate_task、find_energy_efficient_cpu中被频繁调用，验证容量感知在调度关键路径中的核心作用。

五、常见问题与解答

Q1：异构平台小核容量不是 512，是什么原因？

解答：容量由设备树capacity-dmips-mhz与最大频率共同决定。若小核最大频率低于默认值，或设备树配置的capacity-dmips-mhz非 100，归一化后容量会偏离 512。需检查设备树配置与cpufreq驱动是否正常。

Q2：大核频繁被轻负载任务占用，小核空闲，如何排查？

解答：1. 检查内核是否开启CONFIG_SCHED_CAPACITY与CONFIG_SCHED_ENERGY；2. 用ftrace跟踪capacity_of返回值，确认大核容量为 1024、小核为 512；3. 检查任务load值，轻负载任务load应 < 512；4. 关闭自定义调度插件，避免干扰默认异构调度规则。

Q3：DVFS 调频时，CPU 容量会变化吗？

解答：会。capacity_of返回的是当前容量，随频率线性变化：当前容量 = (当前频率/最大频率) × 原始容量。例如大核原始容量 1024，当前频率为最大频率的 50%，则capacity_of返回 512。

Q4：同构平台（如树莓派 4B）容量均为 1024，调度器如何处理？

解答：同构平台所有 CPU 容量一致，capacity_of返回相同值，调度器退化为普通 CFS 负载均衡，按负载均分任务，无大核 / 小核区分。

Q5：如何修改内核，自定义 CPU 容量比例？

解答：修改kernel/sched/capacity.c中的归一化逻辑，或在设备树中调整capacity-dmips-mhz值。例如将小核capacity-dmips-mhz设为 50，归一化后容量为 256，调度器会将其视为更低算力核心。

六、实践建议与最佳实践

6.1 内核配置与编译建议

  • 必开 EAS：异构平台务必开启CONFIG_SCHED_ENERGY，否则仅基础容量感知，无能耗优化，调度效果差。
  • 关闭无关调度插件：如CONFIG_SCHED_MC、CONFIG_SCHED_SMT，避免干扰异构负载均衡。
  • 设备树精准配置：严格按 CPU 微架构设置capacity-dmips-mhz，数值偏差会导致容量计算错误，引发调度失衡。

6.2 异构系统性能调优技巧

  • 任务绑定策略：前台交互任务（UI、输入）绑定大核，后台任务（同步、推送）绑定小核，避免抢占。
  • DVFS 调频策略：大核启用performance模式（高负载时满频），小核启用powersave模式（低负载时降频），平衡性能与功耗。
  • 容量阈值优化：修改can_migrate_task中的负载阈值（默认 512），根据业务调整重负载判定标准，如游戏场景可设为 768，确保核心算力充足。

6.3 调试与问题排查规范

  • 优先查容量值：调度异常时，先通过/sys/devices/system/cpu/cpu*/cpu_capacity确认容量是否正确，避免无效排查。
  • Ftrace 跟踪关键函数：重点跟踪capacity_of、can_migrate_task、find_energy_efficient_cpu，定位容量判断与任务放置异常。
  • 结合 perf 分析负载：用perf top查看任务负载，确认高负载任务是否在大核、低负载是否在小核，快速定位调度失衡根因。

6.4 内核定制开发建议

  • 不修改 capacity_of 核心逻辑：capacity_of是调度器基础接口，修改会影响所有依赖容量的模块，优先通过设备树、调度参数调整。
  • 扩展容量感知维度：可基于capacity_of新增温度感知，CPU 温度过高时动态降低容量，调度器自动迁移任务到低温核心，提升系统稳定性。

七、总结与应用延伸

本文从理论概念、环境搭建、结构体定义、核心源码逐行解析、用户态实操、问题排查到工程最佳实践，完整拆解了 Linux CPU 容量感知capacity_of与异构计算调度机制。capacity_of本质是异构系统的算力标尺，通过归一化容量量化大小核性能差异，为调度器提供精准的任务放置与负载均衡依据，核心价值是让合适的任务跑在合适的核心上，实现性能与功耗的最优平衡。

从工程应用来看，该机制是智能手机、ARM 服务器、工业实时控制等异构场景的底层调度支撑；从内核开发与学术研究角度，掌握capacity_of与异构调度原理，可深入理解 Linux 调度器的性能感知、能耗优化、负载均衡设计思想，可直接用于内核论文撰写、异构系统性能调优、定制化调度策略开发。

建议读者基于本文提供的源码、实操命令与调试方法，在树莓派或异构开发板上复现实验，修改内核调度参数观察调度行为变化，真正做到从理论到实战吃透 Linux 异构调度核心原理。

# linux # 运维 # 服务器
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

cover

ComputePilot 系列（二）：从模型库到 vLLM 推理服务，跑通 AI 服务发布

avatar openEuler 社区
cover

Windows 回收站深度解析：从原理到取证

avatar openEuler 社区
cover

实验三十一：配置DHCP中继代理

avatar openEuler 社区