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