我在分析程序行为方面做了一些工作。我想做的一件事是获取进程在CPU上运行的时间。我通过阅读Linux内核的 sched_entity 数据结构中的 sum_exec_runtime 字段来完成此任务。
用一些相当简单的程序测试它之后只执行一个循环然后退出，我遇到了一个特殊的问题，就是程序每次执行时都没有完成相同的运行时。看作 sum_exec_runtime 是一个以纳秒为单位的值，我希望该值在几微秒内有所不同。但是，我看到几毫秒的变化。
我最初的反应是，这可能是由于I / O等待时间，但我的理解是该进程应该在等待I / O时放弃CPU。此外，我的测试程序只是执行循环，所以应该很少甚至没有I / O.
我正在寻求以下任何建议：
请记住，我只是试图找到进程在CPU上执行的实际时间。我不关心总执行时间，包括睡觉或等待跑步。
编辑：我还想明确我的测试程序中除了循环之外没有分支，循环只需循环一定数量的迭代。
感谢。
答案 0 :(得分：1)
您的问题非常广泛，但出于各种原因可能会导致上下文切换。调用大多数系统调用涉及至少一个上下文切换。页面错误导致上下文切换。超过时间片会导致上下文切换。
sum_exec_runtime等于来自utime的{{1}} + stime，但/proc/$PID/stat以纳秒为单位。听起来你只关心sum_exec_runtime这是你的进程在用户模式下安排的时间。有关详细信息，请参阅proc(5)。
您可以查看utime自愿和非自愿，nr_switches也是sched_entity的一部分。这可能会解释大多数变化，但我不希望连续运行是相同的。每次运行所获得的确切时间将受到系统上运行的所有其他进程的影响。
如果您正在执行任何IO，您还会受到系统上使用的文件系统缓存量以及连续运行中获得的文件系统缓存命中数的影响。
为了给出一个非常具体而明显的示例，说明其他进程如何影响当前进程的运行时间，请考虑是否超出了物理RAM限制。如果你的程序要求更多的RAM，那么内核将花费更多的时间交换。该时间交换将计入stime，但会根据您需要多少RAM以及可用RAM量而有所不同。其他流程有很多其他方法可以影响流程的运行时间。这只是一个例子。
回答你的3分：
sum_exec_runtime是调度程序运行进程的实际时间，包括系统时间