linux - 使用 bogomips 估计 cpu 周期有多合理？

Question

如果我有一个长时间运行的进程，它在完成工作时平均使用 10% 的 CPU，并且我并行运行它的两个副本，我可以预期它们总共使用 20% 的 CPU中央处理器。或者，如果我在速度两倍的不同 CPU 上运行一个副本，我预计它会使用该 CPU 的 5%。

我想做的是处理此类进程的 CPU 要求，但以合理的 CPU 相关方式，即不是百分比。

我想知道通过将其 CPU 百分比乘以我测量它的机器的 bogomips 数，为这样的应用分配一个简单的“每秒需要的周期数”数字可能有多大意义。也就是说，在 bogomips 值为 1000 的机器上使用 10% CPU 的进程可以说每秒需要 100,000,000 条(伪造的)指令。

(免责声明:我当然知道 bogomips 是伪造的，指令不等于周期，周期和指令时序在不同的处理器系列之间根本不可比。我在这里寻找粗略的线性比较，而不是精确计数。)

更详细一点:假设我有一个系统，其中有各种各样的长时间运行的进程在一台可能受 CPU 限制的机器上运行。我可能想提前预测它们是否都能在 CPU 不重载的情况下运行。或者我可能想要执行检查(简单的检查)，以确保没有进程使用比预期更多的 CPU。我愿意提前根据经验衡量每个过程的性能，以帮助我做出这些预测并实现这些检查。我在这里探索的是，衡量性能的正确单位是什么？

例如，今天我可能在处理器 X 上运行进程 A、B、D、E 和 H。我可能会观察到进程使用的 CPU 百分比为 10%、5%、1%、5% 和 20% ， 分别。 10+5+1+5+20 是 41，41 小于 100，所以我很好。

但明天我可能想在以一半时钟速率运行的不同处理器 Y 上运行进程 A、B、C、H 和 J。即使我也对进程 C 和 J 的性能有所了解，当 CPU(百分比所在的)是一个移动目标时，尝试基于百分比进行数学计算似乎不必要地困惑。

如前所述，我可能还想为每个长时间运行的进程分配一个明确的 CPU“预算”，为了理智起见，我可能希望该预算随着时间的推移保持合理有效。也就是说，我可能想说进程A每秒只允许使用100,000,000个周期。如果它曾经使用过 150,000,000，那就有问题了。但是，如果明天我将所有内容都转移到速度提高 2 倍的 CPU，我不希望进程 A 能够使用两倍的 CPU，因为我可能会考虑将额外的 CPU 能力用于其他进程。

最后，如果这有任何意义，并且如果乘以 bogomips 不是做我想做的事情的好方法，有人有更好的主意吗？

(哦，还有一个免责声明:对于多处理器机器和多核处理器，这个问题显然变得更加复杂。我稍后会担心这些额外的皱纹，而不是今天。)

Answer 1

完全不合理。不，认真的。确实，有人提议删除 bogomips，正是因为它们毫无意义，但由于它破坏了某些用户的功能而被覆盖:https://lwn.net/Articles/627930/ (搜索“bogomips”)。