パスワードを忘れた？ アカウント作成
Close
7342 story

FreeBSD -CURRENT のスケジューラが 4BSD から ULE に 10

ストーリー by wakatono
SMP環境の性能改善に前進 部門より

BSD 曰く、 " Jeff Robersonが 関係者にあてたメールによると、 FreeBSD -CURRENT の GENERIC カーネルで採用されるスケジューラが 従来の SCHED_4BSD から SCHED_ULE に変更されたとのことだ。 この新スケジューラは SMP に対応するため、カーネル内でのロック処理を 大幅に見直した結果、多くのプロセスが資源の要求で競合するような場合、 従来のスケジューラよりきびきびと動くと言われている。 カーネル自体は、5.2-RELEASE で既に SMP 対応に変わっている。 残るはスレッドライブラリのKSE化であるが、これも 5.3-RELEASE までには 正式採用される予定である。 これらのカーネルの改良には、今後も目を離せないと思う。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FreeBSD -CURRENT のスケジューラが 4BSD から ULE に More

  • ULEに関する論文 (スコア:3, 参考になる)

    by tag (10007) on 2004年01月26日 14時56分 (#481141) 日記
    Jeff Roberson 自身が書いた ULE に関する論文があります。 System V や Linux の事情、ULEの仕組み、ベンチマーク等に ついて詳細に述べられていて参考になります。
    ULE: A Modern Scheduler For FreeBSD [chesapeake.net]

  • タイトルの入力間違い (スコア:1)

    by tag (10007) on 2004年01月26日 11時50分 (#481027) 日記
    あまりにも大胆に間違っているので誰も気がつかないようですが、 -CURRENTの間違いですね。 「BSDの日記」 [srad.jp]のほうも間違っている ようなので、元のタレコミ自体が間違ってるようです。

  • なってますね [slashdot.org]。

    なんか、本題のスケジューラーよりもGNU/KFreeBSD [debian.org]の話で盛り上がってる [slashdot.org]みたいですが。

  • シングルプロセッサの場合 (スコア:0)

    by Anonymous Coward on 2004年01月26日 9時38分 (#480931)
    も、性能改善されるものなのでしょうか？

    # SMP時の性能改善だけでも、手放しで嬉しいです

    • Re:シングルプロセッサの場合 (スコア:2, 興味深い)

      by WATT (7709) on 2004年01月26日 11時20分 (#481006) 日記
      リンク先のメールを読む限りでは、HT付きP4だとUPでも効果がありそうですね。他の物だとどうなんでしょう。

      以前(といっても5.1Rを過ぎたぐらい)のULEだと、単純な計算とかを並列させた場合には、SCHED_4BSDのほうが速かったです。
      あれから、様々なチューニングもされてますし、ジャイアントロックを減らす努力もなされているようなので、だいぶ状況は変わっているのかなと思います。

      # 年度末の計算の嵐で、試せるリソースはしばらく無さそう
      シェア
      親コメント

      • 昔のベンチマークの結果 (スコア:3, 参考になる)

        by tag (10007) on 2004年01月26日 11時41分 (#481019) 日記
        5.1-RELEASEの時のベンチマークが以下のリンクで紹介されています。
        UNIX USER 2003/08 [itmedia.co.jp]
        今では改善されていて、こんなひどい結果にはならないと思います。
        シェア
        親コメント

      • Re:シングルプロセッサの場合 (スコア:2, 参考になる)

        by Jadawin (2174) on 2004年01月28日 14時03分 (#482796) 日記
        メーリングリストのfreebsd-currentで、関連しそうなのをざらっと読んでみたのですが、、、

        UniProcessorでも、アプリケーションを切替える時など、ユーザの操作に対する反応は
        良くなるようです。

        ちなみに、今ULEのkernelで動かしているんですが、setiathomeのCPU占有率が、以前は
        96%ぐらいになっていたのですが、ULE_SCHEDだと75%前後です。

        ＃setiathomeは、nice 15付きです。

        そこから想像するに、GUI関連の反応は良くなっても、純粋計算系(例えば、コンパイル)
        などは、2～3割遅くなるんじゃないかと。
        シェア
        親コメント

  • -lpthread (スコア:0)

    by Anonymous Coward on 2004年01月26日 13時23分 (#481107)
    今 -pthread で build しているアプリケーションは、近い将来
    には -lpthread がより適当になるのでしょうか？

    libpthread の予定ご存知の方教えてください。
typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人