如何分析perf sched脚本和perf sched延迟?

时间:2018-06-08 13:45:07

标签: linux perf

我用perf sched记录来记录一些东西。

我从 perf sched脚本

获得了一些 上下文切换 事件
filebench  2646 [000] 21159.177699:       sched:sched_switch: filebench:2646 [120] **R** ==> rcu_sched:8 [120]

filebench  2611 [000] 21159.172060:       sched:sched_switch: filebench:2611 [120] **T** ==> filebench:2645 [120]

filebench  2618 [000] 21159.193692:       sched:sched_switch: filebench:2618 [120] **S** ==> rcu_sched:8 [120]

filebench  2620 [000] 21159.193724:       sched:sched_switch: filebench:2620 [120] **D** ==> filebench:2628 [120]

字符R / T / S / D的平均值是什么?

另一个问题: 为什么cs时间在perf sched延迟和perf sched脚本之间有所不同?

1 个答案:

答案 0 :(得分:2)

字符R/T/S/D代表各种任务状态。

字符“R”表示任务处于 TASK_RUNNING 状态。字符“S”表示任务已被置于 TASK_INTERRUPTIBLE 状态。字符“D”表示调度程序已将任务置于 TASK_UNINTERRUPTIBLE 状态。最后,字符“T”表示该任务当前处于<​​strong> TASK_STOPPED 状态。要了解如何从字符中确定任务状态,请查找linux内核(4.17)源代码: -

TASK_STATE_TO_CHAR_STR macro

#define TASK_STATE_TO_CHAR_STR "RSDTtZXxKWP"

/* task state bitmask, copied from include/linux/sched.h */
#define TASK_RUNNING        0
#define TASK_INTERRUPTIBLE  1
#define TASK_UNINTERRUPTIBLE    2
#define __TASK_STOPPED      4
#define __TASK_TRACED       8
/* in tsk->exit_state */
#define EXIT_DEAD       16
#define EXIT_ZOMBIE     32
#define EXIT_TRACE      (EXIT_ZOMBIE | EXIT_DEAD)
/* in tsk->state again */
#define TASK_DEAD       64
#define TASK_WAKEKILL       128
#define TASK_WAKING     256
#define TASK_PARKED     512

这就像将第一个字符“R”引用到第一种任务状态一样简单 - 即TASK_RUNNING,将第二个字符“S”引用到TASK_INTERRUPTIBLE状态,类似于第三个字符'D'指的是TASK_UNINTERRUPTIBLE ......这种情况一直持续到最后'W'指的是TASK_WAKING而'P'指的是TASK_PARKED。请注意,任务状态EXIT_TRACE与宏字符串TASK_STATE_TO_CHAR_STR中的任何字符都不对应。

对于第二个问题,很难看出哪个输出代表perf sched latency,哪个输出代表perf sched script。您也很难分析如何分析两个输出。您必须记住perf sched latency按任务汇总调度程序延迟。它向您展示了每个任务,它的最大延迟是什么,它的运行时间以及执行期间有多少次上下文切换与其他一些细节分开。另一方面,perf sched script将转储类似于perf script命令的所有调度程序事件。

这两个命令非常不同,任何直接比较都会导致错误的结论。

相关问题