☰

time 命令如何从 4 毫秒计时器滴答声中计算出一毫秒？

tag-icon • tag-icon linux time cpu-usage clock interrupt
time 命令如何从 4 毫秒计时器滴答声中计算出一毫秒？

time从不同的 Ubuntu 系统（包括真实硬件和虚拟机）上的bash命令来看CONFIG_HZ=250，我有时会得到real 0m0.001s或user 0m0.001s任何sys 0m0.001s其他毫秒数。

这怎么可能 ？

编辑：我承认real可以通过在命令开始和结束时查询任何可用的高分辨率时间源来精确计算经过的 ( ) 时间time。
但由于出于性能原因，系统调用进入或退出时没有时间源查询，因此我预计 CPU 时间的计算user会sys以计时器滴答数（计时器中断的数量）为单位，该滴答数将是 4 毫秒的倍数。

第二次编辑：考虑到 MC68020 的答案，问题变为：Linux 内核如何能够从系统调用返回user微秒sys精度的 CPU 使用情况getrusage？
当我争论出于性能原因不能在每个系统调用入口和出口上进行时间源查询时，我是否做错了？

答案1

正如您可以阅读的一些代码

#if defined (HAVE_GETRUSAGE) && defined (HAVE_TIMEVAL) && defined (RUSAGE_SELF)
...
  getrusage (RUSAGE_SELF, &self);
...
  print_timeval (stdout, &self.ru_utime);
...
#else
#  if defined (HAVE_TIMES)
...
  times (&t);
  print_clock_t (stdout, t.tms_utime);
...

根据 HAVE_GETRUSAGE、HAVE_TIMEVAL 和 RUSAGE_SELF 设置，bash 的time内部命令将使用格特鲁萨奇系统调用或次系统调用。

getrusage如果使用case ，则 bash 的time命令将使用 rusage 结构的 ru_stime 和 ru_utime 成员，并根据上面链接的手册页计算其关联的 timeval 结构的成员，微秒精度。

如果times使用系统调用，则 bash 的time命令将输出关联的 Clock_t 结构的成员。在这种精确的情况下，值确实以时钟周期报告，因此您正确的写法是报告值的精度不能优于 1/CONFIG_HZ。

正如您可能在times系统调用手册页中读到的那样，由于多种原因不鼓励使用它。所以我相信您系统中的设置（HAVE_GETRUSAGE ...）适合使 bash 不必求助于它。如果不是，那么……你是对的，你报告的精度只是……荒谬。

A/ 为什么 getrusage 可以比 1/CONFIG_HZ 更精确地报告计时： 因为 ：

从Linux 2.6.21开始，Linux支持高分辨率定时器（HRT），在支持HRT的系统上，睡眠和定时器系统调用的精度不再受到jiffy的限制，而是可以在硬件允许的情况下尽可能精确（微秒精度是现代硬件的典型精度）。

正如您可以在本文中读到的时间和计时器概述。

B/ 如果没有在每个系统调用开始时正确设置计时器并在完成后立即读取，如何才能实现有关 utime/stime 的准确性：

精确的CPU时间：谁在乎 ？调度员！调度程序在其完全公平共享归因，不要忘记其承担处理任务的义务，愿意……nanosleep……
什么CPU时间？ :当然是总计！也就是说 u_time + s_time 因为（除了一些非常罕见的例外）调度程序根本不关心任务如何（在哪种情况下）浪费它们的时间片。
那么谁关心 s/u 时间比率呢？ ： 中央处理器会计爱好者们！

B.1/ 那么……区分 u_time 和 s_time ？……让我们……假设！

在 Linux 的（好？）旧时代（了解 < 大约 2.6。？ 内核）CPU 计数是某种简单（主义？）启发式：当某个任务被调度时，调度程序会记录该任务的上下文正在运行并且......：

cpu 会计会很高兴假设：自从调度任务以来，任务一直在运行的所有时间都花在调度出去时它正在运行的上下文中！

由此，人们可以理解，由于时钟精度如何而对用户和系统 cpu 时间单独报告的准确性进行争论在某种程度上是毫无意义的：只是在确定什么是什么时存在错误。随着时间的推移，错误会累积。唯一的机会，加上任务在其生命周期内被调度进/出的次数可以帮助CPU时间统计爱好者期望 + 中的错误将补偿 - 中的错误，因此无论这些值的意义是什么（因为它们是分开考虑的）总和仍然确实、准确且有意义）

B.2/ 错误还可以，但是……没那么严重！那么……让我们开始吧……虚拟！

在具有虚拟 CPU 的系统上，当虚拟平台上使用的虚拟 CPU 多于真实 CPU 时，真实 CPU 可能会花费部分时间为另一个虚拟处理器服务，而时间片可能会被某些实际上无法利用它的进程占用。
这不仅导致了错误的而且完全不切实际的 s_time 数字。

长话短说，大约是2.6。？内核，linux 附带了虚拟CPU时间统计除其他功能外，只要执行上下文发生变化，就可以提供 CPU 时间统计，从而实现明确、精确和准确的 u 时间和 s 时间。

与任何地方一样，没有免费的午餐……（每个 cpu）计时器无处不在……预计会有一些重大的开销。

没关系，许多顶级发行版（RHEL、SUZE...）很快就将这种虚拟 CPU 时间统计设置为默认值。

没关系（我个人）感谢自 3.7 以来提供的一些内核可调（ CONFIG_TICK_CPU_ACCOUNTING ），（并且 AFAIK 在股票 Linux 版本上仍然默认）我仍然可以选择（好？）旧的 cheep cpu 会计方法，因为......我（个人）只关心关于 u_time + s_time 的总和。

这将是所有人;-)

答案2

该time工具不是必需的使用该times()功能，不是吗？正在times()看着CONFIG_HZ是的。但这并不是唯一与时间相关的函数。

例如，函数clock_gettime()转到硬件时钟并忽略CONFIG_HZ.并且粒度clock_gettime()仅受硬件限制。你的 CPU 越好 - 就越精确clock_gettime()。

相关内容