今月初め、Linux5.18サイクルの前にLinuxスケジューラの変更がsched/coreにキューイングされていることに気付きました。さまざまなワークロードでAMDEPYCプロセッサやその他の選択されたZenプロセッサを支援することが期待されています。この変更は数か月間行われており、複数のLLCにまたがる場合に許可されるNUMAの不均衡を調整することを目的としています。私は今、EPYCハードウェアでいくつかの独自のベンチマークを実行し、実際にLinuxカーネルのパフォーマンスをさらに向上させています。
パッチは素晴らしいパフォーマンスの向上を示しています…今は私の側でテストしています。
来月のLinux5.18マージウィンドウの前に「sched/core」にキューイングされたこの変更は、AMD固有の変更ではなく、キャッシュレイアウトのためにZenプロセッサに利益をもたらす変更です。パッチを作成したMelGorman氏は、次のように説明しています。「[2020年からのカーネルスケジューラの変更]により、通信タスクがロードバランサーによって引き離されないように、NUMAノード間の不均衡が許容されました。独立したタスクがキャッシュを共有するCPUを時期尚早に使用する場合、複数のLLCには最適ではない可能性があります。Zen*にはローカルメモリチャネルを備えたノードごとに複数のLLCがあり、許容される不均衡のため、一部のワークロードを調整して最適に実行することは、現在よりもはるかに困難です。ノードごとに1つのLLCを持つハードウェア。このパッチにより、ノード間でLLCのバランスをとる必要があるポイントまで不均衡が存在する可能性があります。」
さまざまなEPYC7003シリーズのパフォーマンスが大幅に向上していることを確認できます。最新のTIPスケジュール/コアの変更を伴うワークロードの数。
このパッチで作業するときのMel自身のベンチマークでは、Streamメモリベンチマークが最大272％向上し、Coremarkでのパフォーマンスが10％向上するなどの大きなメリットもありました。と最大最大17％、SPECjbb Javaパフォーマンスは18％も向上し、NPBの驚異的並列ベンチマークは約17％速くなり、その他の注目すべき勝利がありました。報告された非常に有望な結果を考えると、私はローカルでいくつかの独自のテストを実行しており、私が見ている数も同様にエキサイティングです-特にこのLinuxカーネルスケジューラの変更では、約50行の新しいコードです！
最初に、ASRockRack ROME2D16-2Tマザーボードを中心に構築され、Ubuntu21.10を実行しているAMDEPYC 75F32Pサーバーで実行されたベンチマークをいくつか示します。 Linux 5.17 Gitと、問題の「sched/fair:SD_NUMAが複数のLLCにまたがる場合に許可されるNUMAの不均衡を調整する」パッチを適用したsched/coreGitのパフォーマンスを比較しました。両方のカーネル間で同じカーネルKconfigが使用されました。