📚 课程目录第3章调度器debugfs接口总览

3. 调度器debugfs接口总览：/sys/kernel/debug/sched/ 目录结构及各文件功能概览

Linux 内核调度器通过 debugfs 文件系统暴露了丰富的调试与统计接口，挂载点通常位于 /sys/kernel/debug/sched/。这些接口为性能分析工程师提供了“手术刀”级别的观测能力，能够直接读取调度器内部的数据结构、运行队列状态、负载均衡统计以及抢占/唤醒延迟等关键指标。本章将系统性地梳理该目录下的核心文件及其功能，为后续的深度分析实践打下基础。

挂载检查： 在访问接口前，请确认 debugfs 已挂载。执行 mount | grep debugfs，若未挂载，使用 mount -t debugfs none /sys/kernel/debug 进行挂载。

3.1 目录结构全景图

以下 SVG 图展示了 /sys/kernel/debug/sched/ 下的主要文件与子目录，按照功能域划分为：调度特性开关、运行队列与负载统计、延迟与抢占追踪、域与组拓扑 四大模块。

3.2 核心文件功能详解

下表按照功能分类，逐一说明每个关键文件的作用、数据格式及典型分析场景。这些文件是进行调度器性能分析时最常使用的入口。

功能域	文件名	核心功能	数据格式/典型输出	分析场景
调度特性开关	`features`	列出并控制调度器特性（如 GENTLE_FAIR_SLEEPERS、NO_HZ_COMMON）的启用状态	每行一个特性，前缀 `#` 表示禁用，无前缀表示启用	调试特定调度行为；对比特性开关前后的性能差异
调度特性开关	`features_debug`	暴露仅用于调试的调度特性，通常不用于生产环境	与 `features` 格式相同	内核开发与调度器行为验证
运行队列与负载	`rq_stats`	每个 CPU 运行队列的详细统计：nr_running、nr_switches、load 等	多行文本，按 CPU 编号分组展示	CPU 负载均衡分析；识别运行队列堆积
	`loadavg`	系统平均负载（1/5/15 分钟），与 `/proc/loadavg` 类似但更底层	三个浮点数，如 `0.85 0.62 0.41`	宏观系统负载趋势监控
	`nr_running`	当前系统中处于 TASK_RUNNING 状态的进程总数	单个整数	快速判断系统是否过载
	`nr_uninterruptible`	当前处于 D 状态（不可中断睡眠）的进程数	单个整数	排查 I/O 等待或锁竞争导致的进程阻塞
延迟与抢占追踪	`sched_latency`	调度延迟统计：从任务进入运行队列到实际获得 CPU 的时间分布	直方图或统计摘要（min/max/avg）	评估调度器响应速度；识别长延迟异常
	`preempt_stat`	记录抢占发生的次数、原因（内核态/用户态）及被抢占任务信息	按 CPU 和原因分类的计数	分析抢占频率；优化实时性
	`wakeup_latency`	测量从唤醒事件发生到被唤醒任务开始执行的时间	直方图或时间戳序列	实时系统延迟分析；中断响应性能评估
域与组拓扑	`sched_domain_debug`	展示调度域（sched_domain）的层级结构，包括 CPU 掩码、负载均衡标志	树状文本，显示每个域的 span、flags、balance_interval	验证 NUMA 拓扑配置；调试负载均衡策略
域与组拓扑	`sched_group_debug`	展示调度组（sched_group）的成员 CPU 及组内负载信息	按域分组的 CPU 列表与负载值	细粒度负载均衡分析；组间迁移决策验证

3.3 典型接口使用示例

以下代码片段展示了如何快速读取关键接口，获取调度器状态快照。

# 查看当前启用的调度特性（无#前缀表示启用）
cat /sys/kernel/debug/sched/features

# 输出示例（部分）：
# GENTLE_FAIR_SLEEPERS
# NO_HZ_COMMON
# WAKEUP_PREEMPTION
# 注意：不同内核版本输出不同

# 查看每个CPU的运行队列统计
cat /sys/kernel/debug/sched/rq_stats

# 输出示例（部分）：
# CPU0: nr_running=2, nr_switches=1024, load=512
# CPU1: nr_running=1, nr_switches=980, load=256

# 查看调度域拓扑结构
cat /sys/kernel/debug/sched/sched_domain_debug

# 输出示例（部分）：
# domain0 (MC): span=0-3, flags=SD_BALANCE_NEWIDLE|SD_BALANCE_EXEC
#   group0: cpus=0-1, load=128
#   group1: cpus=2-3, load=96

  分析技巧： 在性能问题排查初期，建议同时采集 rq_stats、nr_running 和 sched_latency 三个文件的数据。它们分别提供了“每个 CPU 的负载分布”、“全局运行队列深度”和“调度延迟质量”三个维度的信息，能够快速定位是负载不均、全局过载还是调度延迟异常导致的问题。

3.4 接口使用注意事项

权限要求： 访问 debugfs 接口通常需要 root 权限，或确保用户属于 debug 组。
性能开销： 频繁读取 rq_stats 或 sched_latency 等统计接口会引入少量锁竞争，在生产环境中建议使用间隔采样（如每 5 秒一次），避免持续高频率读取。
内核版本差异： 部分接口（如 wakeup_latency）在较老内核（如 4.x 系列）中可能不存在，或输出格式不同。建议在目标内核上先执行 ls /sys/kernel/debug/sched/ 确认可用接口。
动态修改风险： 向 features 文件写入内容可以动态启用/禁用调度特性，但不当修改可能导致系统性能下降或行为异常。建议在测试环境中验证后再应用到生产系统。

安全提醒： 不要在生产环境中随意向 features 写入 NO_GENTLE_FAIR_SLEEPERS 等特性开关，除非你完全理解该特性对交互式任务响应延迟和吞吐量的影响。错误的配置可能导致桌面环境卡顿或数据库事务延迟飙升。

3.5 接口与性能分析流程的映射

以下 SVG 图展示了从性能问题现象到对应 debugfs 接口的映射关系，帮助分析人员快速选择合适的调试入口。