静态tracepoint预埋在内核的关键位置, 通过这些预埋的tracepoint, 可以比较容易梳理出相关模块的框架及主要流程. 相比于直接钻到scheduler的实现细节中去, 我们先通过tracepoint及其相关工具去理解实现背后的逻辑, 细节总是不停变化, 而分析方法往往相对固定, 也更容易沉淀下来.

Tracepoint分类

通过perf命令可以列出系统所有的tracepoint:

核心tracepoint

• sched_switch

• sched_wakeup

• sched_waking

• sched_migrate_task

Stat类型

该类型的tracepoint额外带有delay的时间

• sched_stat_blocked

• sched_stat_iowait

• sched_stat_runtime

• sched_stat_sleep

• sched_stat_wait

其他

• sched_kthread_stop, sched_kthread_stop_ret. 在kthread_stop时产生, 一般不是scheduler性能调试的重点

• sched_move_numa, sched_swap_numa, sched_stick_numa. NUMA相关, 从性能分析角度上看, 它们必须在我们的checklist中, 一定程度可以把它们当作是异常(USE)

• sched_pi_setprio. 用于实现rt_mutex的优先级继承, 比如用在futex上.

• sched_process_exec, sched_process_exit, sched_process_fork, sched_process_free. 进程相关的主要事件

• sched_process_hang. 进程hang

• sched_process_wait. 等子进程的状态变化

• sched_wait_task. 等待其他任务unschedule, 比如用于ptrace.

• sched_wake_idle_without_ipi. 如果target cpu上的任务设置了TIF_POLLING_NRFLAG标记 (只有idle进程会设置), 这样idle进程自己去poll TIF_NEED_RESCHED, 这样就不用发ipi中断去通知了

• sched_wakeup_new. 同sched_wakeup, 但针对的是新创建的任务

核心Tracepoint

sched_switch

当调度器决定schedule另一个task运行的时候, 也就是任务切换的时候, 会触发该tracepoint. 核心逻辑如下:

我们稍微关注以下context_switch里面的切栈操作:

注意这里的__switch_to_asm传入了prev, 又返回了prev, 看似没有必要, 但是因为context_switch函数涉及到2个task, 在切栈之前是A, 切栈之后就变成B了

• 对于切栈前的task A来说, prev指的就是A本身

• 对于切栈后的task B来说, prev指的还必须是A, switch到B之后还需要更新A的信息. 这里通过函数调用巧妙解决了2个task之间变量的传递.

ULK引入3个task来解释switch_to, 我认为反而复杂了.

sched_wakeup / sched_waking

内核会通过try_to_wake_up把任务唤醒, 这会涉及到这sched_wakeup和sched_waking两个tracepoint.

上面需要关注的点:

• 可以唤醒current task

• 唤醒on_rq的task比较直接, 在sched_waking和sched_wakeup之间的时间非常短

• 当需要迁移到其他cpu时会有2种方案

• 通过ipi给target cpu发送中断, 在中断处理函数中完成wakeup的后面部分

• 直接在当前cpu上操作target cpu, 所以需要先执行rq_lock操作, 可能会有锁冲突

从上面可以看出, sched_waking和sched_wakeup在wakeup task过程中肯定都会发生, sched_waking事件在ttwu开始的时候触发, 而sched_wakeup在ttwu结束的时候触发. 一般情况下, 这2个tracepoint触发的时间非常靠近, 但是不排除中间会有较大gap.

sched_migrate_task

从资源的角度看, 只有系统中存在多个同类资源(这里是cpu), 为了最大化资源利用率, 就会涉及到migration. 从性能角度看, 这个的影响是比较大的, 也是性能调试的时候必须关注的, migration有没有及时, migration会不会太多 (locality).

【文章福利】小编推荐自己的Linux内核技术交流群:【749907784】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！（含视频教程、电子书、实战项目及代码)     

零声白金VIP体验卡（含基础架构/高性能存储/golang/QT/音视频/Linux内核）课程：

Stat类型

为了使用stat类型的tracepoint, 我们需要先enable.

stat_iowait / stat_sleep / stat_blocked

• stat_sleep用于记录TASK_INTERRUPTIBLE的时间

• stat_blocked用于记录TASK_UNINTERRUPTIBLE的时间

• stat_iowait用于iowait的场景, 这种情况下stat_iowait和stat_blocked值是一样的

stat_wait

stat_wait和上面的stat不一样的地方在于, stat_wait更反映调度器本身的执行情况.

• wait的起始时间wait_start. 任务状态切到runnable, 但是不能马上在cpu上执行

• task被抢占了, 那么wait_start就是抢占点. put_prev_entity并且prev->on_rq成立

• task唤醒的时候, 从enqueue_entity进入

• wait的结束时间

• 任务马上要在cpu上执行了, set_next_entity

• 任务enqueue后压根没能在该cpu上执行就被dequeue了, update_stats_dequeue

stat_runtime

记录任务的执行时间, 包括runtime, vruntime

Scheduler框架

__schedule()的主要逻辑

性能调试

即使不是调度器的开发者, 有的时候也需要能够对调度器进行调试, 比如应用开发者或者系统管理员, 升级内核后性能退化, 修改线程模型后性能不满足预期等, 最终可能只需要动某个调度器的参数而已, 但是前提是能够定位到这个参数.

sched map

只要抓取sched:sched_switch一个tracepoint, 就可以抓到系统所有的切换事件, 以下perf sched map的输出:

• 前面每列代表一个cpu, 后面2列是事件发生的时间戳和任务缩写的映射

• 点(.)表示cpu在idle

• 星号(*)表示有事件发生

sched timehist

该命令可以获得task的wait time, 特别地, 还能拿到sch delay. timehist统计的sch delay是通过sched_switch和sched_wakeup计算出来的, 而不是上面的stat_wait.

sched latency

这里的delay同timehist的sch delay.

perf inject

通过关联以下2个tracepoint, 我们可以得到任务sleep的时长及其对应的callchain

• sched_iowait/sleep/blocked. 获得sleep的时长

• sched_switch. 获得调用栈

其他

这里列出一些调试的想法, 暂时没有整理和一一展开

• 性能调试要考虑工具的开销, 比如perf的开销是否会影响到应用的性能. 我们可以使用eBPF重写上面的perf的功能, eBPF因为能够在内核中直接聚合, 开销相比perf会小

• 虽然tracepoint能提供更多更完整的调试信息, 但是其他的统计工具比如schedstat等对调试也会有帮助, 很多时候只能用这些一直在搜集的信息, 而不是所有场景都能复现然后上去通过tracepoint搜集信息的

• 以上涉及的工具都还是文本界面的, 图形界面的工具会更有优势. 文本的好处是可以再加工, 图像的好处是更直观, 更容易发现问题

• 和scheduler相关的性能问题主要是两个方面, 一是怎么定位应用程序的off-cpu, 二是scheduler自身的影响, 都有一些相对固定的方法

• 有了这些tracepoint以及动态添加的kprobe, 我们很容易拿到应用程序schedule相关的信息, 比如在context switch in/out时收集信息, 就可以生成带callchain的off-cpu flamegraph

• 如果某个cpu忙应该看到什么现象, 我们可以去获取cpu runqueue的长度

• 如果task的某个函数执行时间过长, 我们可以检查它是在cpu上执行慢, 还是在等资源. 如果是调度不及时, 我们可以看到当时它runnable的时长, 以及其他cpu的状态

• 如果我们已经有了cpu视角和task视角, 我们看到大量cpu idle而只有某个task在跑, 那么一种合理的推测是该task是否阻塞其他task了

• 调试其实就是把很多现象关联起来, 也就是说孤立地去看一种现象往往收获不大. 一般来说我们可以通过时间轴把这些事件关联起来, 从资源的角度(比如每个cpu的在任意时间的使用情况), 从消费者的角度(比如每个进程的运行状态/路径)

• 如果某个cpu忙其他cpu闲会有什么现象, 以每个cpu为视角, 通过时间轴把所有的cpu关联起来, 使用不同的颜色表示runqueue的长度, 这样生成的图可以很容易看出migration是否及时, 这样的资源利用图是非常有必要的, 有点类似htop, 但是更加精细

原文作者：J.FW