Linux perf
工具(前段时间名为perf_events
)有几个内置的通用软件事件。其中最基本的两个是:task-clock
和cpu_clock
(内部称为PERF_COUNT_SW_CPU_CLOCK
和PERF_COUNT_SW_TASK_CLOCK
)。但他们的错误在于缺乏描述。
man perf_event_open
{{3}}有简短描述:
PERF_COUNT_SW_CPU_CLOCK
This reports the CPU clock, a high-resolution per-
CPU timer.
PERF_COUNT_SW_TASK_CLOCK
This reports a clock count specific to the task
that is running.
但描述很难理解。
有人可以就task-clock
和cpu-clock
事件的计算方式和时间给出权威答案吗?它们与linux内核调度程序有什么关系?
当task-clock
和cpu-clock
给出不同的值时?我应该使用哪一个?
答案 0 :(得分:2)
1)默认情况下,perf stat
显示task-clock
,而不显示cpu-clock
。因此,我们可以知道task-clock
应该有用得多。
2)cpu-clock
只是被破坏了,多年没有修复。最好忽略它。
预期,cpu-clock
中的sleep 1
将显示大约1秒。相反,task-clock
将显示接近零。使用cpu-clock
来读取挂钟时间是很有意义的。然后,您可以查看cpu-clock
和task-clock
之间的比率。
但是在当前实现中,cpu-clock
等效于task-clock
。甚至有可能“修复”现有计数器可能会破坏某些用户空间程序。如果有这样的程序,Linux可能无法“修复”此计数器。 Linux可能需要定义一个新的计数器。
例外:配置一个或多个CPU时-与特定任务相反-例如perf stat -a
。 perf stat -a
显示cpu-clock
而不是task-clock
。在此特定情况下,预期这两个计数器是等效的。在这种情况下,cpu-clock
的初衷更为合理。因此,对于perf stat -a
,您可以忽略此差异,并将其解释为task-clock
。
如果您编写自己的代码来描述一个或多个CPU(而不是特定任务),那么遵循perf stat -a
的实现可能是最清晰的。但是您可以链接到这个问题,以解释您的代码在做什么:-)。
主题:Re: perf: some questions about perf software events
来自:Peter ZijlstraFrank Bui-Huu在2010年11月27日星期六14:28 +0100写道:
Peter Zijlstra写道:
Franck Bui-Huu在2010年11月24日星期三12:35 +0100写道:
[...]
我目前还没有看到cpu-clock和 任务时钟事件。他们俩似乎都在计算 任务正在CPU上运行。我错了吗?
不,弗朗西斯(Francis)已经注意到,当我添加 多pmu的东西,在我的待办事项清单上可以查看(弗朗西斯还递给了我 一点补丁),但我一直对其他东西不感兴趣:/
好。
调整两者的期限是否有意义?
此外,在创建任务时钟事件时,将'pid = -1'传递给 sys_perf_event_open()真的没有意义,对吗?
与cpu时钟和'pid = n'相同:无论值如何,事件度量 cpu墙上的时钟。
也许在API中仅提出一个时钟并将其内部绑定 时钟到CPU或任务时钟取决于pid或cpu参数 更好了吗?
不,在任务上同时计算CPU和任务时钟实际上很有意义 (CPU时钟基本上是挂钟)。
答案 1 :(得分:1)
根据this message,他们衡量同样的事情。
他们在采样时只是有所不同。
cpu-clock是基于挂钟的 - 所以样本是定期进行的 相对于壁时的间隔。 我相信任务时钟与任务运行时间有关。所以, 样品是相对于过程定期拍摄的 运行时。
当我在我的多线程应用程序上运行它时,它确实显示了几乎相同的值。
答案 2 :(得分:0)
一般来说: cpu-clock事件测量时间的流逝。它使用Linux CPU时钟作为定时源。
这是一篇关于使用perf http://sandsoftwaresound.net/perf/perf-tutorial-hot-spots/
查找执行热点的深入文章任务时钟告诉您作业的并行程度/使用了多少cpu。 本纲要包含perf生成的输出的详细信息: https://doc.zih.tu-dresden.de/hpc-wiki/bin/view/Compendium/PerfTools