【问题标题】:What are some factors that could affect program runtime?有哪些因素会影响程序运行时间?
【发布时间】:2014-10-29 15:45:53
【问题描述】:

我正在做一些关于分析程序行为的工作。我想做的一件事是获取进程在 CPU 上运行的时间。我通过读取 Linux 内核 sched_entity 数据结构中的 sum_exec_runtime 字段来完成此操作。

在使用一些相当简单的程序进行测试后,这些程序只是执行一个循环然后退出,我遇到了一个特殊的问题,即程序每次执行时都不会以相同的运行时结束。看到 sum_exec_runtime 是一个以纳秒表示的值,我希望该值在几微秒内有所不同。但是,我看到了几毫秒的变化。

我最初的反应是,这可能是由于 I/O 等待时间造成的,但据我了解,该进程应该在等待 I/O 时放弃 CPU。此外,我的测试程序只是在执行循环,所以应该很少甚至没有 I/O。

我正在就以下问题寻求任何建议:

  1. sum_exec_runtime不是进程控制 CPU 的实际时间吗?
  2. 进程在等待 I/O 时实际上并没有放弃 CPU 吗?
  3. 是否还有其他因素会影响进程的实际运行时间(I/O 除外)?

请记住,我只是想找出进程在 CPU 上执行的实际时间。我不关心总执行时间,包括休眠或等待运行。

编辑:我还想明确一点,我的测试程序中除了循环之外没有任何分支,循环只是循环进行恒定次数的迭代。

谢谢。

【问题讨论】:

  • 预计该测量中会出现噪音,尤其是在运行时间较短的程序中。各种事情都会影响它。做大量的平均。

标签: process linux-kernel profiling scheduling


【解决方案1】:

您的问题非常广泛,但您可能会因各种原因导致上下文切换。调用大多数系统调用涉及至少一个上下文切换。页面错误会导致上下文切换。超过您的时间片会导致上下文切换。

sum_exec_runtime 等于来自/proc/$PID/statutime + stime,但sum_exec_runtime 以纳秒为单位。听起来您只关心utime,这是您的进程在用户模式下安排的时间。详情请见proc(5)

您可以查看nr_switches 自愿和非自愿,它们也是sched_entity 的一部分。这可能会解释大多数变化,但我不希望连续运行是相同的。每次运行获得的确切时间将受到系统上运行的所有其他进程的影响。

如果您正在执行任何 IO,您还将受到系统上使用的文件系统缓存数量以及在连续运行中获得多少文件系统缓存命中的影响。

为了给出一个非常具体和明显的例子来说明其他进程如何影响当前进程的运行时间,请考虑您是否超出了物理 RAM 限制。如果您的程序要求更多 RAM,那么内核将花费更多时间进行交换。该时间交换将计入stime,但会根据您需要多少 RAM 和可用 RAM 多少而有所不同。其他进程可以通过许多其他方式影响您的进程的运行时间。这只是一个例子。

回答你的 3 点:

  1. sum_exec_runtime 是调度程序运行进程的实际时间包括系统时间
  2. 如果您将切换到内核视为放弃 CPU 的进程,那么可以,但这并不一定意味着一旦内核完成,另一个用户进程可能会重新获得 CPU。
  3. 我想我已经回答了这个问题,有很多因素。

【讨论】:

  • 我假设您将 stime 称为睡眠时间?我的理解是 sum_exec_runtime 不包括睡眠时间。但是,如果是这种情况,我想这是我的实现有缺陷。感谢您的反馈。
  • stime 是系统时间。
  • 在系统时间+用户时间的情况下,我确实关心两者。我只是不想包括任何花费在睡觉或等待跑步上的时间。我相信无论系统上运行的其他进程的数量如何,花费在 CPU 上的时间应该是相同的。睡眠时间和等待时间应该根据进程的数量而变化。
  • 这个假设是错误的。您的系统具有其他进程正在竞争的共享资源。
  • 好的,根据您上次的编辑,我现在可以看到我可能应该只收集 utime。我会做更多的研究来研究如何做到这一点。感谢您的帮助。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-10-09
  • 1970-01-01
  • 2016-05-04
  • 2022-01-14
  • 1970-01-01
  • 2011-10-27
  • 2020-11-28
相关资源
最近更新 更多