我正在运行一个基准来确定我应该允许 GNU Make 使用的作业数量，以便获得最佳编译时间。为此，我使用 N 编译 Glibc，make -j<N>其中 N 是 1 到 17 的整数。到目前为止，我每次选择 N 都做了 35 次（总共 35*17=595 次）。我还使用GNU Time运行它来确定 Make 花费的时间和使用的资源。
当我分析结果数据时，我注意到一些奇怪的东西。当我达到-j8.
我还应该注意，8 是我计算机上的 CPU 内核数（或者更具体的超线程数）。
在自愿上下文切换的数量上，我也可以注意到同样的事情，但不那么明显。
为了确保我的数据没有偏差或其他任何问题，我又运行了两次测试，但仍然得到相同的结果。
我正在使用 linux 内核 5.15.12 运行 artix linux。
这些尖峰背后的原因是什么？
编辑：我在 4 核 PC 上再次做了同样的实验。我可以观察到同样的现象，这次是 4 个工作岗位。
此外，请注意 2 个作业标记中主要页面错误的跳跃。
编辑2：
@FrédéricLoyer 建议将页面错误与效率（经过时间的倒数）进行比较。这是一个确切的箱线图：
我们可以看到，随着我们从 1 个工作变为 4 个工作，效率越来越高。但对于更多的工作，它基本保持不变。
我还应该提到我的系统有足够的内存，所以即使有最大数量的作业，我也不会用完内存。我还记录了 PRSS（峰值驻留集大小），这是它的箱线图。
我们可以看到作业的数量根本不会影响内存使用。
EDIT3：正如 MC68020 所建议的，这里分别是 4 核和 8 核系统的 TLBS（事务后备缓冲区击穿）值图：
当
make启动一个进程时，进程的内存被映射到它的文件（可执行文件，库）。然后预计会看到页面错误。系统效率越高，我们可以预期的页面错误就越多。将页面错误率与效率（与所花费的时间成反比）进行比较可能会很有趣make。当系统没有足够的 RAM 并与 HDD 交换数据时，我们也可能会出现页面错误。这不是效率的标志。
因为您显示全局效率的图表为您的任务提供了正确的答案，所以我将尝试专注于解释。
A/效率\工作安排
理论上，（假设在 make 启动时所有 CPU 都处于空闲状态，并且在启动第 n 个 > i 时没有其他任务正在运行，并且没有 i 作业已经完成），我们可能期望 CFS 分配 1、2、3、4、5， 6,7,8 个作业到 CPU 0,2,4,6（因为缓存共享没有好处）然后 1,3,5,7（缓存共享仍然没有好处但是因为缓存在兄弟姐妹之间共享，增加锁争论因此对全球效率产生负面影响）这是否足以解释从工作 5 开始全球效率缺乏改进？
B/页面错误
正如 Frédéric Loyer 所解释的，在作业启动时预计会出现重大页面错误（由于必要的读取系统调用）。您的图表显示，从 5 个职位增加到 8 个职位几乎是恒定的。在我看来，4+4 内核上 -j4 的显着增加（由 2+2 内核上的 -j2 显着增加证实）看起来更有趣。这可能是由于任何其他任务引起的某些 <=4 cpu 的突然活动而在 > 4 cpu 上重新安排一个作业线程的见证吗？-j(n>8) 的恒定页面错误数量可以通过所有可以选择的 cpu 已经具有适当映射的事实来解释。
顺便说一句：只是为了证明我对杂项的要求。OPs 评论中的缓解信息，我想首先确保您的所有核心都可以完全运行。他们似乎是。