使用 make -jnproc 導致頁面錯誤數量激增
我正在執行一個基準來確定我應該允許 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（事務備份緩衝區擊穿）值圖：
因為您顯示全域效率的圖表為您的任務提供了正確的答案，所以我將嘗試專注於解釋。
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 評論中的緩解資訊，我想首先確保您的所有核心都可以完全執行。他們似乎是。