Linux kernel 如何分析性能计划记录的性能数据

我使用以下方法收集了一些性能数据：

perf sched record –g

我需要分析这个命令生成的性能数据

我正在使用以下命令进行分析：

perf report 

我看到多个sched事件：

62K sched:sched_switch                                                                                                  ▒
0 sched:sched_stat_wait                                                                                                 ▒
0 sched:sched_stat_sleep                                                                                                ▒
0 sched:sched_stat_iowait                                                                                               ▒
120K sched:sched_stat_runtime                                                                                           ▒
10 sched:sched_process_fork                                                                                             ▒
31K sched:sched_wakeup                                                                                                  ▒
10 sched:sched_wakeup_new                                                                                               ▒
873 sched:sched_migrate_task    

打开其中一个事件后，我看到如下内容：

+   80.00%     0.00%  ksmtuned  bash               [.] make_child
+   80.00%     0.00%  ksmtuned  libc-2.17.so       [.] __libc_fork
+   80.00%     0.00%  ksmtuned  [kernel.kallsyms]  [k] stub_clone
+   80.00%     0.00%  ksmtuned  [kernel.kallsyms]  [k] sys_clone
+   80.00%    80.00%  ksmtuned  [kernel.kallsyms]  [k] do_fork
+   10.00%     0.00%      bash  bash               [.] make_child

我无法解释这些信息。 以下是我的问题：

1） 显示%值的前两列是什么？ 2） 为什么%的值加起来不等于100%？

---

3） 这些数字的意义是什么？

perf.sched record

是perf的特殊变体，我认为使用

perf.sched

子命令分析生成的

perf.data

文件更为正确

perf sched

上有手册页：

桌面用户通常会使用“perf sched record”来捕获跟踪 （创建性能数据）和“perf sched latency”工具进行检查 延迟（分析性能数据中的跟踪）。其他工具也是 使用已记录的性能数据

---

Brendan Gregg的网站可能会有所帮助：这是一个很好的教程，但并没有回答我所有的问题。@maverick9888，为什么不使用

perf sched

子命令来分析

perf sched record

的结果呢？检查并“[宣布]‘性能调度’：用于捕获、测量和分析调度程序延迟和行为的实用程序”，2009年。Sched不能与

perf report

一起使用，但是

perf.data

可以通过

perf report

打开。你的目标是什么？它没有完全回答我的问题，因为它非常有用，所以仍然被接受。谢谢。@maverick9888，您只是尝试使用错误的命令，

perf report

用于解析统计配置文件，而sched是跟踪配置文件的变体。所以报表将无法正确计算开销（百分比字段）。我的方案是一个复杂的bi。在我的应用程序中有一个渲染循环。而且随机的一次迭代需要更多的时间（~1000微秒）。我希望收集精确的1000微秒间隔的数据。在进行性能测量时，有没有办法放置围栏？i、 e.将1秒性能数据线性拆分为1000*1000个部分？@maverick9888，当帧渲染速度较慢时，您能否在应用程序中记录精确的时间点（在帧渲染结束时调用

gettimeofday（）

，并使用ns将该时间打印到某个文件中）？然后您将能够在

perf sched script

输出中找到该时刻。另外，您可以尝试一些跟踪解决方案（有很多，在中列出），例如lttng（它可以跟踪内核事件，如调度器和用户空间跟踪点-lttng ust，由您定义，例如帧渲染开始和结束的时刻）@osgx：我用你的想法从应用程序中记录时间，并尝试将其与perf数据中的时间戳匹配。应用程序时间戳和性能时间戳之间的时间差很大。例如，性能数据中的第一个时间戳为177898.937847秒，而性能启动时应用程序中的时间戳为177829.251676秒。我运行perf工具1秒钟。在perf工具完成后，我终止了我的应用程序。应用程序最后报告的时间是177830.617393。应用程序的最后一个时间戳位于性能数据中的第一个时间戳之后。我们能把这些时间戳联系起来吗？

       'perf sched record <command>' to record the scheduling events
       of an arbitrary workload.

       'perf sched latency' to report the per task scheduling latencies
       and other scheduling properties of the workload.

       'perf sched script' to see a detailed trace of the workload that
        was recorded...

       'perf sched replay' to simulate the workload that was recorded
       via perf sched record. (this is done by starting up mockup threads
       that mimic the workload based on the events in the trace. These
       threads can then replay the timings (CPU runtime and sleep patterns)
       of the workload as it occurred when it was recorded - and can repeat
       it a number of times, measuring its performance.)

       'perf sched map' to print a textual context-switching outline of
       workload captured via perf sched record.  Columns stand for
       individual CPUs, and the two-letter shortcuts stand for tasks that
       are running on a CPU. A '*' denotes the CPU that had the event, and
       a dot signals an idle CPU.

  perf sched record            # low-overhead recording of arbitrary workloads
  perf sched latency           # output per task latency metrics
  perf sched map               # show summary/map of context-switching
  perf sched trace             # output finegrained trace
  perf sched replay            # replay a captured workload using simlated threads