Question

我在Embedded Linux(Kernel 2.6.37)上运行了ARM。来自top的默认busybox 1.13.2。我通过交叉编译构建procps-ng 3.3.11以在此Linux上运行。我发现来自%cpu和top的{{1}}来自busybox输出的流程不同。

例如，一个进程的procps-ng %cpu显示约30％，但procps-ng top仅显示约10％。来自busybox top和%cpu的总procps-ng top是相同的然后，我阅读了busybox top和busybox的计算源代码。我发现它们对于一个进程procps-ng确实有不同的计算公式。

%cpu

为什么这两个项目选择不同的计算公式？他们是为不同的应用案例设计的吗？谢谢！

Answer 1

与procps-ng团队讨论了这个问题，这是关键点：

2016年12月28日下午03:12，Craig Small写道：
  可能有不同的方式来看待这个。我要说的第一件事就是busybox应该模仿或模仿主程序应该做的事情，所以如果busybox和真实程序之间存在差异，我会说busybox是错误的。这就像busybox ls打印文件与真实ls不同。

让我们再看一下这个公式：



busybox top：
  CPU% = s->pcpu/sum(s->pcpu) * busy_cpu_ticks/total_cpu_ticks
  （pcpu是sys的delta +样本之间的用户时间）



procps-ng top：
  CPU% = s->pcpu/total_cpu_ticks



现在让我们重新安排一下：


busybox top：
  CPU% = s->pcpu/total_cpu_ticks * busy_cpu_ticks/sum(s->pcpu)
  CPU% = top_CPU% * busy_cpu_ticks/sum(s->pcpu)
  （pcpu是sys的delta +样本之间的用户时间）


这是不同的。 busybox添加了busy_cpu_ticks/sum(s->pcpu)与最佳效果的比率。这个比例可以写成：

RATIO = Sum(Usr + Nice + System + Irq + sirq + steal) / Sum(Usr + System)

您可以在busybox来源的read_cpu_jiffy中看到这一点。我不    了解这个比例试图做什么或为什么需要它。特别是当您尝试模拟的程序没有它时。
     在这个循环中，从顶级可用的jiffies中可以看出，这个程序使用了X％。 busybox在那里放了一些奇怪的缩放。因此，如果进程在其系统和用户部分中使用10％的CPU，则top显示10％。如果该周期该过程在用户和系统中占50％的时间，则busybox将显示20％（10％x 100/50）。

我不知道他们为什么那样做。

请参阅讨论链接了解更多详情：
discussion: different process's %cpu output via top from busybox and procps-ng

不同进程的cpu输出来自busybox和procps-ng的top

1 个答案: