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

カーネル2.5、最新開発動向 42

ストーリー by kazekiri
賞味期限付き 部門より
@ITにgotom氏による Linuxカーネル2.5の現状について網羅された解説記事が掲載 されている。最近の変化が読みやすく書かれている。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

カーネル2.5、最新開発動向 More

  • 見えないdispatch delayが残りそう (スコア:3, 参考になる)

    by brake-handle (5065) on 2002年04月09日 17時27分 (#80049)

    Preemptionについては本当にsourceや他のOSの実装を見たのか疑わしいところがあります。現状のLinux kernelではlock primitiveが貧弱です(特に、adaptive/blocking lockで十分なところにspin lockを使っている)。これはkernelのあちこちでinterrupt levelを引き上げることになります。結果として、割込そのものが遅れるために測定不可能なdispatch delayが生じる恐れがあります。

    FreeBSDの場合、最も基本となるlockはblocking lock(多くは将来adaptiveに変更予定)です。spin lockはscheduler lockなど4種類しか用いていません。また、割込も、本質的にはspin lockにおけるlock attempt(1回のattempt毎に1回割込を許可)、pmap変更、clock割込以外では一切禁止しません。なおかつ、一部ではGiantが外れている(そのうちkernel memory allocatorから外れる、これは大きい)ため、すでに(点ではなく線に対して)preemptionが可能になっています。

    • 補足 (スコア:1)

      by brake-handle (5065) on 2002年04月09日 17時45分 (#80056)

      FreeBSDの場合、i386ではsysctlによりpreemption不可能であっても許可することが可能です。この場合、割込threadが実行可能でなければ通常通りrun queueにぶち込まれます。違いは、その後にmi_switch()を呼び出さない(通常は呼び出すので割込threadが直ちに実行される)というだけです。

      シェア
      親コメント

      • 補足の補足 (スコア:1)

        by brake-handle (5065) on 2002年04月09日 17時47分 (#80057)

        s/不可能であっても許可する/不可能であっても割込を許可する/

        シェア
        親コメント

      • Re:補足 (スコア:0)

        by Anonymous Coward
        Linuxの場合、spin lockでも割り込み可能なのと 不可能なのといろいろあります。だから、 spin lockだからといって、即、割り込み不可能とは いえないんじゃないでしょうか？
    • ＞割込そのものが遅れるために測定不可能なdispatch delayが生じる恐れがあります
      ＯＳの実装についての知識不十分なため、基本的なところで外した質問かも知れませんが、
      簡単に言っちゃうと、記事でリアルタイム機能が実装されている（若しくは実装されつつある）ようなことが書かれているが、それは間違いである、ということでしょうか？
      或いは、それっぽい機能は実装されているけど、実質的にはリアルタイムには全然なってない、てことでしょうか？
      シェア
      親コメント

      • Re:見えないdispatch delayが残りそう (スコア:2, 参考になる)

        by Anonymous Coward on 2002年04月09日 18時07分 (#80067)
        端的に言えば、preemption は必要なんだけど、preemptive なだけでは不十分で、現状 Linux カーネルの至る所で使われてる spinlock を何とかしないと仏を作って魂入れず状態だ、ということやね。
        シェア
        親コメント

        • なぜpreemptionを行うのか (スコア:2, 参考になる)

          by brake-handle (5065) on 2002年04月10日 8時16分 (#80304)

          元記事をもう1ど読んで気になったのですが、そもそも「なぜkernelをpreemptableにするか」という問題意識が元記事からは読み取れません。これではpreemptionがrealtime向けにしかならないというような誤解を与える恐れがあります。

          一般に、OSにおけるschedulingの問題は以下の2種類に分けられます。

          • 各threadに与える優先度をどのように決めるか
          • 決めた優先度をどのようにしてcpu割り当てに反映させるか

          前者の問題はいわゆるscheduling policyです。これは本来applicationによっていかようにも決められるべきものです(実際、SVR4/MPやSolarisではschedulerを自分で作ることが可能)。一方、後者ではdispatch delayが問題になります。その大きな原因としては(preemptionができないなどlockに依らないものも含めた)優先度逆転があります。解法としてはkernelをpreemptableにする、優先度継承を行うなどの方法が知られています。

          まとめると、本来kernel preemptionなどで実現したいのは「ありとあらゆるscheduling policyを支える仕組み」です。preemptionを取り上げるなら、どんなscheduling policyにも応えることができる仕掛けの1つとして書いて欲しかったなぁ...

          シェア
          親コメント
          • ＞SVR4/MPやSolarisではschedulerを自分で作ることが可能
            げっ！そんなことまでできるんだ。確かにタイミングがクリティカルな用途（音楽再生とか、データ収集とか）などでなくとも、そういう機能は欲しいですが、実際に実装するとなると飛んでもないことになるはずなので諦めてたんですが．．．．既にできてたとは。Solaris恐るべし．．．．。
            ＃しかしそうなると、x86のサポートなくなったことがホントに痛いなぁ。
            シェア
            親コメント
    • Linux には spl がないから割り込みレベルが上がることは無いので平気(大嘘)
    • まーそんなわけで、FreeBSD の SMP は Linux の 2 年くらい先を行ってるし、
      5.0 が安定すれば、4 ないし 16 CPU くらいのいわゆるミッドレンジの
      エンタープライズユースで十分スケールすると思うんだわさ。

      というわけで、そろそろ Oracle きぼんぬ。
      そうすれば、Linux の上、Solaris の下、くらいの市場に食い込めると思うんだがなぁ。
      • >>4 ないし 16 CPU くらいのいわゆるミッドレンジの
        >>エンタープライズユースで十分スケールすると思うんだわさ。

        これを示す数字ってどっかに無いですか？ カーネルが7.5秒でコンパイルできた [srad.jp]とかの類のいい加減なデータで も教えてくださるとありがたいです。
        シェア
        親コメント
      • FreeBSD5.0のDeveloper Preview #1が出ましたね
        リリースノート [freebsd.org]も出てます。
        そろそろ誰かたれこんだりしてるかな。

        うちには残念ながらSMPとか試す余裕のあるマシンはありませんが
        それ以外でもいろいろと楽しみにしてたり。
        それはそうとJ2DKはどうなってるんだろう…。
        linuxエミュレーションのJDKの新しいパッチは出てるみたいだけど
        シェア
        親コメント
      • まー性能はしらんけどシェアは数年後ろ行ってるわな。
        良いOSだとは思うけど、今のままじゃマニアOS路線から抜け出せるとは思えん。
        商用で成功するには嫌でもユーザーに媚びんと。
        それにBSDIにしてもWindRiverにしても後ろ盾が弱すぎるわな。ケツ割るのも早いし。
        実際のところ、Linuxを抜くなんて現状では夢のまた夢でしょ。

        • Re:そんなに大事？ (スコア:1)

          by maruchan (4547) on 2002年04月10日 12時39分 (#80397)
          シェア？ シェアねぇ…。 そんなに大事ですか？シェアって。 申し訳無いけど、それじゃM$と変わらないような気がします。 まぁマニアOSと言われようと（実際そういう面もあると思いますよ、僕だって）何と言われようと、別に気にせず僕は使いつづけると思うし、むしろシェアがどうこうとか言うくだらない事よりも、FreeBSDには今のように「使い倒そうとしたときに、とっても具合が良い」OSであり続けて欲しいなぁ。 ただそれだけ…。
          シェア
          親コメント

          • Re:そんなに大事？ (スコア:1, 興味深い)

            by Anonymous Coward on 2002年04月10日 13時12分 (#80410)
            最初のコメントがシェアの低さを嘆くようなものだったから、シェアを上げたいのならマーケの基本として性能以外にも扱い易さだとかそれなりにやる事があるだろって事を言ったまで。Oracleを使いたいって事ならシェアは間違いなく大事でしょ。
            LinuxはLinuxのやり方で頑張ってる、FreeBSDはFreeBSDのやり方で頑張ってる。それでいいと思う。お互い意識し過ぎずそっとしておけばよいことです。
            私はメインLinuxでFreeBSDもたまに使ってます。適材適所で使えればそれで結構。一番嫌なのは伝統だとか裏付けの無い風説などで無条件にFreeBSDがLinuxより優れてると主張するFreeBSD派が私の周りには多い事。ビジネスシーンでメリットを主張したいのなら裏付けを持った上でしっかりアピールして欲しいものです。
            そう、アピールがたらんのよ。FreeBSDは。
            シェア
            親コメント

            • Re:そんなに大事？ (スコア:1)

              by maruchan (4547) on 2002年04月10日 13時30分 (#80415)
              >LinuxはLinuxのやり方で頑張ってる、FreeBSDはFreeBSDのやり方で頑張ってる。それでいいと思う。お互い意識し過ぎずそっとしておけばよいことです。

              良いこと言いますな～（笑）。
              そう！そうなんです！

              >私はメインLinuxでFreeBSDもたまに使ってます。適材適所で使えればそれで結構。

              比率が逆だけど、僕も両刀です。
              それぞれ良さがある（Linuxはディストリ次第っつー面もあるけど）んで、みんな両方使ってみればいいのになぁ…。
              シェア
              親コメント

          • Re:そんなに大事？ (スコア:0)

            by Anonymous Coward
            Linuxには当初からの弱者意識が振りほどけない人が多いんでは。
            これだけ普及したんだからもう少し自信を持てばいいのにね。

            Linuxはさすがにそろそろ、相対的にしか自分の位置や価値を
            確認できないという状況は脱しつつあると思うんだが。
        • 単純にインストールベースのシェアならMacOSXの存在でBSDがLinuxよりも多くなることは確実ですが。
          いくらLinuxが普及したとはいえ、コンシューマ向けマシンにプリインストールされているOSを数の上で上回るのは難しい。
          MacOSXをBSDとして使っている人はその中のごく一部だろうということで、意味のある比較だとは思いませんが。
          --
          うじゃうじゃ
          シェア
          親コメント

        • 頭悪そう… (スコア:0)

          by Anonymous Coward
          >まー性能はしらんけどシェアは数年後ろ行ってるわな。

          WEBサーバとしてはLinuxよりxBSDの方がシェアが大きいと思っていたのですが。

          • Re:頭悪そう… (スコア:0)

            by Anonymous Coward
            日本でのシェアはすでに逆転していますな。 FreeBSDはLinuxの1/3 http://unixuser.softbankpub.co.jp/hot/0205/hot.html
      • 5.0 が安定すれば
        何年かかりますか？
        予想としては安定するのに３年かかってその間にLinuxに抜かされてるに128カノッサ。
        • 3.x, 4.x の実績からすると、 (n+1)-CURRENT がスタートして
          n-CURRENT が n-STABLE となってからだいたい半年くらい
          (リリース二回、つまり n.2-RELEASE)で安定してますね。

          Linux 2.6.xでのリリースエンジニアリングは2.4.xみないに
          ならないことを期待。

          ま、ソースの見えるOS同士、切磋琢磨していったらいいと思います。
      • http://www.samag.com/documents/s=1148/sam0107a/0107a.htm あたりをみるとLinuxの方がスケーラビリティ(？) があるように見えるのですが、FreeBSDの方が優れ ているという定量的なデータってありますか？
      • どんなわけで？ バザール的な話をすると、Linuxの開発者の数って、量的に圧倒しているような気がするんですよね。
        IBMなんかはLinuxの専従(パッチつくったり、バグフィックスしたり性能評価したりする人)が100人以上いるし、国産F/H/Nでも数十人規模でいるし、(もちろん商用
    • adaptive/blocking lockって何でしょうか？ 素人にもわかる解説へのポインタ希望
    • >Preemptionについては本当にsourceや他のOSの実装を見たのか疑わしいところがあります。
      多分見ていないでしょうね。solarisは7の時点でspin/adaptive/block lockを持っていましたし。

      またプロセスのCPU配分についても

      また、複数のプロセッサを持つシステムでは、プロセスがCPU間で不定に割り当てられてしまう（プロセスがCPU間を動き回る
    • Linuxの場合、spin lockでも割り込み可能なのと不可能なのといろいろあります。だから、spin lockだからといって、即、割り込み不可能とはいえないんじゃないでしょうか？
      • spin lockとはpreemptionされないとは限りません。
        つまり割り込みが可能なspinと不可能なspinがあるのは別に特殊な訳ではありません。
        spinが問題になるのは、adaptive/block lockに比べ、システム全体のプロセッサ時間を無駄にしてしまう可能性があるということです。
        またlockの優先度の逆転を防ぐために優先度の継承を行う実装を取ることが多く、
        • >> spinが問題になるのは、adaptive/block lockに比べ、システム全体のプロセッサ時間を無駄にしてしまう可能性があるということです。
          可能性があるというのは否定できないのですが、今のlinux2.5で実際にlock contentionを発生している例を示していただけないでしょうか？ (多くのcontentionはlock primitiveの選択を間違えているというよりも、lockのかけ方が不適切であることによって発生していると思われます)

          adaptive/block lockの方もスケジューラを呼び出してコンテキスト切り替えをするオーバヘッドがありますので、十分に短い区間であればspinしていたほうが有利な可能性もあります。
          シェア
          親コメント
          • 上のanonです。

            私はlinuxの人ではないのでlinuxの実装について言うのは控えさせていただきます。
            上の投稿で言いたかったのは一つにはspinだからといってpreemptionされないとは限らないということ。
            もう一つはtabateeさんのおっしゃるとおり、lockのかけ方が不適切な実装もあるわけで、
            その場合spinはadaptive/blockに比べ無駄時間が多いということです。

            もちろん即応性については一般にspinはadaptive/blockより良いので、当たり前のことですが使い分けが重要と言いたかったわけです。
            例えばマルチプロセッサ
            • 私は即応性/realtime性/応答時間については、不勉強なのでコメントできませんが

              >>lockのかけ方が不適切な実装もあるわけで、 その場合spinはadaptive/blockに比べ無駄時間が多いということです。
              確かにそうですが、lockのかけ方が不適切な場合には安易にlockの種類を変えるよりもlockのかけ方を直すのが正攻法だと思います。
              すくなくともlinuxは今までこの方針である程度の改善ができていて、また、しばらくは同じように改善し続けることができると私は考えています。

              ちなみに、32プロセッサ使ってカーネルを7.5秒でコンパイルできた話 [lwn.net]の最後の方のプロファイルをみても以前まであったlock contentionはほとんど消えているように見えます。
              シェア
              親コメント
              • 上のanonです。

                >確かにそうですが、lockのかけ方が不適切な場合には安易にlockの種類を変えるよりもlockのかけ方を直すのが正攻法だと思います。
                まったく同意です。
                私もそもそも使い方が不適切なものはどうやっても駄目だと思います。

                >すくなくともlinuxは今までこの方針で

  • 賞味期限... (スコア:2, 参考になる)

    by dai (252) on 2002年04月10日 3時41分 (#80270) ホームページ 日記
    こちら [kernelnewbies.org]なら、適宜更新されている [kernelnewbies.org]ので賞味期限切れの心配は無用。
    『読みやすく書かれている』とは言えないが、BK採用以降のChangeLogの読み難さから考えればとても良く整理されている。

  • PowerPCって (スコア:1)

    by Mizuki (4740) on 2002年04月10日 20時54分 (#80550)
    64bit版PowerPCって、もしかしてPOWERのこと？
    間違える人多いですよね。
    話は違うけど、プリエンプティブルカーネルと言われてOS-9を思い出した。懐かしい。

    • Re:OS-9 (スコア:1)

      by SteppingWind (2654) on 2002年04月11日 0時08分 (#80635)

      >プリエンプティブルカーネルと言われてOS-9を思い出した。

      確かOS-9はカーネルレベルではプリエンプティブでは無いはずです. ですからシステムモードでIO待ち等が発生すると, それが終了するまでは他の処理がブロッキングされます. これを防ぐため, デバイスドライバ等のコーディングでは割り込み処理ではフラグを立てるだけにしておいて, ユーザモードの処理でそのフラグを使って判断を行うような記述が推奨されていました.

      この構造を逆手に使うと, システムモードでユーザモードの要求を完全にブロックしておいてハードリアルタイムの処理を行うなんてこともできました.

      シェア
      親コメント
typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー