FreeBSD -CURRENT のスケジューラが 4BSD から ULE に 10
ストーリー by wakatono
SMP環境の性能改善に前進 部門より
SMP環境の性能改善に前進 部門より
BSD 曰く、 " Jeff Robersonが 関係者にあてたメールによると、 FreeBSD -CURRENT の GENERIC カーネルで採用されるスケジューラが 従来の SCHED_4BSD から SCHED_ULE に変更されたとのことだ。 この新スケジューラは SMP に対応するため、カーネル内でのロック処理を 大幅に見直した結果、多くのプロセスが資源の要求で競合するような場合、 従来のスケジューラよりきびきびと動くと言われている。 カーネル自体は、5.2-RELEASE で既に SMP 対応に変わっている。 残るはスレッドライブラリのKSE化であるが、これも 5.3-RELEASE までには 正式採用される予定である。 これらのカーネルの改良には、今後も目を離せないと思う。"
シングルプロセッサの場合 (スコア:0)
# SMP時の性能改善だけでも、手放しで嬉しいです
Re:シングルプロセッサの場合 (スコア:2, 興味深い)
以前(といっても5.1Rを過ぎたぐらい)のULEだと、単純な計算とかを並列させた場合には、SCHED_4BSDのほうが速かったです。
あれから、様々なチューニングもされてますし、ジャイアントロックを減らす努力もなされているようなので、だいぶ状況は変わっているのかなと思います。
# 年度末の計算の嵐で、試せるリソースはしばらく無さそう
昔のベンチマークの結果 (スコア:3, 参考になる)
Re:昔のベンチマークの結果 (スコア:1)
この結果だと、ほぼ全滅ですか…。
今走ってるマシンを止めて、試したい衝動に駆られます(笑
Re:シングルプロセッサの場合 (スコア:2, 参考になる)
UniProcessorでも、アプリケーションを切替える時など、ユーザの操作に対する反応は
良くなるようです。
ちなみに、今ULEのkernelで動かしているんですが、setiathomeのCPU占有率が、以前は
96%ぐらいになっていたのですが、ULE_SCHEDだと75%前後です。
＃setiathomeは、nice 15付きです。
そこから想像するに、GUI関連の反応は良くなっても、純粋計算系(例えば、コンパイル)
などは、2～3割遅くなるんじゃないかと。
タイトルの入力間違い (スコア:1)
Re:タイトルの入力間違い (スコア:1)
-lpthread (スコア:0)
には -lpthread がより適当になるのでしょうか？
libpthread の予定ご存知の方教えてください。
ULEに関する論文 (スコア:3, 参考になる)
/.本家でもストーリーに (スコア:1)
なってますね [slashdot.org]。
なんか、本題のスケジューラーよりもGNU/KFreeBSD [debian.org]の話で盛り上がってる [slashdot.org]みたいですが。