注目★★★★★Lobsters
Linux スケジューラの性能測定、メトリクス選びの致命的な罠
30秒で把握
- 1Linux スケジューラ研究で numactl 制限が最大 3 倍高速化を示したが、後に MIPS 低下が判明
- 2L3 キャッシュ RFO 改善とランタイム短縮の一致が破綻、単一メトリクスの落とし穴を露呈
- 3性能測定では複数メトリクスの整合性を常に確認し、矛盾検出で隠れた誤りを防ぐ必要がある
要約
大学の研究プロジェクトで Linux スケジューラの性能影響を調査した著者が、測定結果の解釈に深刻な誤りを犯した経験を報告している。マルチソケット環境で numactl により単一ソケット制限すると最大 3 倍の高速化が観測されたが、後で気付いたのは L3 キャッシュ読み書きミスの改善度とランタイム短縮が一致せず、実は CPU スループット (MIPS) が大きく低下していたという矛盾だ。同じメトリクスで説明できるはずの 2 つのベンチマークが正反対の挙動を示したことで、初期の「スケジューラ最適化で高速化」という結論が間違っていた可能性に気付いた。測定と解釈の乖離こそが性能研究の最大の落とし穴であり、単一メトリクスでの判断がいかに危険かを示す教訓である。
あなたへの影響
システム性能調査に携わるエンジニアは、単一の性能指標 (レイテンシ・スループット・キャッシュミス等) だけで結論を下さず、複数のメトリクスが矛盾しないか常に検証すべき。
推奨:特にマルチソケット環境でのスケジューリング判定は numactl 制約下でも MIPS 低下の有無を確認することが必須。