Linux 中的 getrusage(RUSAGE_THREAD, ...) 和 clock_gettime(CLOCK_THREAD_CPUTIME_ID,...) 有什么区别？答案

【问题标题】：What is the difference between getrusage(RUSAGE_THREAD, ...) and clock_gettime(CLOCK_THREAD_CPUTIME_ID,...) in Linux?Linux 中的 getrusage(RUSAGE_THREAD, ...) 和 clock_gettime(CLOCK_THREAD_CPUTIME_ID,...) 有什么区别？
【发布时间】：2015-12-30 19:09:05
【问题描述】：

这个问题几乎说明了一切。根据getrusage() 的手册页，它返回：

           struct timeval ru_utime; /* user CPU time used */
           struct timeval ru_stime; /* system CPU time used */

根据clock_gettime() 的手册页，它返回：

   CLOCK_THREAD_CPUTIME_ID (since Linux 2.6.12)
          Thread-specific CPU-time clock.

那么，（线程特定的）“使用的用户/系统 CPU 时间”与线程特定的 CPU 时间时钟有何不同？

显然，我之所以这么问，是因为我在移植到 Linux 的应用程序（来自自定义 RTOS）中发现了两者之间的差异。该应用程序具有使用tick() 和tock() 函数实现的内部分析功能。当我一直在研究这个时，我已经将我的应用程序的一部分退化为：

tick()
// code commented out
tock()

tick() 函数记录它的运行时间，tock() 函数记录它运行的时间，计算两者之间的增量，并报告该增量。当我使用getrusage() 实现tick() 和tock() 时，我得到的主要是0，偶尔会得到1000us 或10000us 的值（根据我是否将内核配置为1kHz 或100Hz 操作）。当我使用 clock_gettime() 实现 tick() 和 tock() 时，我得到的值集中在 13us 左右（偶尔会出现 75us 或 100us 的奇怪偏移，但我稍后会处理）。

我尝试在内核中启用高分辨率计时器以及VIRT_CPU_ACCOUNTING 和/或VIRT_CPU_ACCOUNTING_GEN 的各种组合。我看到的唯一效果是getrusage() 报告的非零值从 1000us 变为以 1000us 为中心的更高精度值范围。

我终于改用clock_gettime() 并且得到了更可信的结果，但我想知道为什么这两个系统调用存在，以及为什么它们的行为如此不同。所以我想我应该问一些专家。

【问题讨论】：

您是否将结果与CLOCK_MONOTONIC进行了比较？
CLOCK_MONOTONIC 是全局的，而不是特定于线程的。我正在寻找一个特定于我的线程的经过时间计时器。
我想知道CLOCK_MONOTONIC 和CLOCK_THREAD_CPUTIME_ID 之间是否存在显着差异。换句话说，如果他们实际上测量了不同的东西。使用strace 也可能有助于了解调用之间的差异。

标签： linux multithreading real-time

【解决方案1】：

getrusage(RUSAGE_THREAD, ...) 和 Linux 中的clock_gettime(CLOCK_THREAD_CPUTIME_ID,…)？

clock_gettime(CLOCK_THREAD_CPUTIME_ID, …) 最终调用task_sched_runtime(p)，它从p->se.sum_exec_runtime 获取计费运行时间，其中struct task_struct *p 是current。

getrusage(RUSAGE_THREAD, …)调用task_cputime_adjusted(current, &utime, &stime)，存在[a]、[b]两个定义；使用哪个取决于Linux内核配置项CONFIG_VIRT_CPU_ACCOUNTING_NATIVE：

选择此选项可启用更准确的任务和 CPU 时间会计。

现在我们需要知道您的内核中是否选择了此选项。无论如何，这两种情况看起来都与clock_gettime()使用的方法不同。

也就是说，我无法重现您的发现（我从两个系统调用中得到的数字几乎相同）。一个示例程序可以提供更多帮助。

所以我想我应该请教一些专家。

我认为您会在 Linux 内核邮件列表中找到真正的专家。

【讨论】：