我试图了解cgroup 子系统cpu.cpu_quota_us中的设置是否对应用程序性能有任何影响。cpu本质上是通过减少 CPU 配额，但增加 CPU 数量，使“有效”CPU 仍然相同，这会影响应用程序吗？例如，4 CPU 100%配额配置与8 CPU 50%配额配置相同吗？
我知道这在很大程度上取决于应用程序设计以及它是否受 cpu 或 io 限制。这里我只关心CPU密集型应用程序。
我的努力：
我写了一个简单的 C 应用程序，可以在这里找到https://github.com/ashu-mehra/cpu-quota-test。
该程序创建“N”个线程。每个线程开始计算从数字“n”到 1000000 之间的素数。每个线程的起始数字“n”都不同。计算完 100 个素数后，线程会休眠固定的时间。一旦线程达到 1000000，就从 2 重新开始。最后，主线程显示每个线程计算的累积素数数量。我将其视为此示例应用程序的“吞吐量”。
我在以下配置下运行该程序：
- 在一个有 4 个 cpu 且没有配额限制的 cgroup 中。
- 在一个有 8 个 cpu 和 50% 配额的 cgroup 中。
我通过将 /sys/devices/system/cpu/cpu/online` 设置为 0 来禁用超线程。
对于每种配置，我将线程数从 4 更改为 32。以下是示例程序生成的“吞吐量”结果。数字是 10 次迭代的平均值。
线程 cpu4quota100 cpu8quota50 4 66229.5 66079.4 8 128129 129768 16 189247 134882 24 188238 98917.8 32 176236 87252.5
请注意，从线程 16 开始，两种情况之间的吞吐量存在很大差异。对于 24 和 32 线程，“cpu8quota50”情况下的吞吐量大幅下降。
我perf stat也有这些运行的结果。我注意到cpu-migrations这perf两种配置之间的差异很大。这是比较
线程 cpu4quota100 cpu8quota50 4 9.6 11.2 8 3252.2 37.9 16 2956.2 4490.5 24 472.6 2347 32 118.3 1727.2
线程 4、8 和 16 的数字有意义，但我无法理解“cpu4quota100”情况下线程 24 和 32 的数字，它们远小于线程 16 的情况。
有人可以解释这些结果吗？另外，“cpu 迁移”对应用程序性能有影响吗？
抱歉，帖子很长！
编辑1：
我更新了运行上述示例程序的脚本，以使用time命令计时执行时间，以查看“cpu4quota100”和“cpu8quota50”情况之间是否有任何差异。我只运行了 32 个线程，结果如下：
时间 cpu4quota100 cpu8quota50 用户 119.956 秒 120.076 秒 系统 0.001 秒 0.009 秒 中央处理器 386.2% 386.5%
user因此，两种情况下的时间和时间差异不大sys，但“吞吐量”是cpu4quota100情况下的两倍cpu8quota50。
编辑2：
改变 CPU 频率的内核调控器似乎有助于提高cpu8quota50案例的吞吐量。早期的数据是在使用频率调节器“powersave”时获得的。在“省电”的情况下，核心的 CPU 频率cpu4quota100会达到最大，但实际上cpu8quota50要低得多。然而，将频率调节器更改为“性能”后，CPU频率在情况下cpu8quota50也接近最大。对于以“性能”作为频率调节器运行的 32 个线程，我得到以下数字：
线程 cpu4quota100 cpu8quota50 32 175804 163831
因此，差异现在已从近 50% 降至仅 6.8%。
但有趣的是，注意到“powersave”调控器在上述两种情况下的行为差异。我不确定它是否按预期工作以防cpu8quota50万一。