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

FreeBSDのSMPngについて 10

ストーリー by Oliver
あっちとこっちとそっちのCPU 部門より

BSD 曰く、 "ONLampにFreeBSD の SMPng についてコアメンバの Scott Long に尋ねた記事が掲載されている。彼の近況、各種ロックの特徴、SMP におけるロックの問題点、NetBSD や OpenBSD、DragonFlyBSD との比較、Linux の SMP との性能比較、KSE や ULE との関連、ハイパースレッディングや巨大なキャッシュの取り扱い、シングルCPUでの性能劣化、PF、IPF、IPFWの性能改善、SMPng の今後の予定等について語られている。今後の FreeBSD の進む方向を知る意味で、非常に興味深いと思う。"

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

FreeBSDのSMPngについて More

  • スピンロックとスリープロック (スコア:4, 参考になる)

    by tag (10007) on 2005年01月23日 18時38分 (#683210) 日記
    Linux でよく用いられるスピンロックと、FreeBSD で用いている スリープロックについて、あちこちのサイトでコメントされているようです。この２つのロックについての説明を引用します。 (参照リンク) [ibm.com]
    • きわめて短時間しか保持されないロックの場合は、スピン・ロックが適している。スピン・ロックにより、待ち状態のスレッドはそのプロセッサを保持し、ロックが使用可能になるまで緊密なループ (スピン) 内でロック・ビットを繰り返し調べることができます。 スピンの結果、CPU 時間が増加します (カーネルまたはカーネル・エクステンション・ロックのシステム時間)。
    • 長時間保持されるロックの場合は、スリープ・ロックが適している。スレッドはロックが解除されるまでスリープ状態に入り、ロックが使用可能になると実行待ち行列に戻されます。スリープの結果、アイドル時間が長くなります。
    本家では以下のようなコメントがありました。
    原文 [slashdot.org]

    Linux uses spinlocks but only when it is certain that it will be released very quickly. It boils down to efficiency. That is because if a lock is held for a very short amount of time, it is more efficient to wait for it than to switch tasks. The Linux design is really to minimize lock hold times by doing as much work as possible without holding locks, and then checking to make sure that things are still right. This technique has allowed Linux to scale linearly up to hundreds of processors. In practice, Linux's SMP implementation has proved to be one of the best.

    Linux はスピンロックを使っているが、それは非常に短時間に ロックが解放される時だけである。これは効率性を重んじている からである。ロックが時間的に最小限の間だけ保持されるなら、 タスクを切り換えるよりも、待つ方がより効率的であるからである。

    一方、OSNewsには、以下のようなコメントがありました。
    (原文) [osnews.com]

    A millisecond is a really long time. Think of it as only being able to recieve 1000 packets a second, or do 1000 disk operations per second. That might not be noticable on a desktop, but is completely useless for a server. There are people using FreeBSD to bridge (i.e. recieve, process and send) 2.5 million packets a second. Any latency at all would render that impossible.

    ミリ秒という単位は非常に長い時間です。1秒で1000パケット受信する こともできるし、1000回のディスク操作をすることもできます。 デスクトップではどちらでもいいかもしれませんが、サーバでは 全く使うことができません。FreeBSD を使って毎秒250万パケット の中継を行っている人がいるのです。

    このあたり、どういう戦略が一番有効なのかは、状況に応じた データを準備して、実際に計測してみるしかないようです。 用途によって、全然違う結果が出ることも考えられると思います。

    • OpenBSD との比較 (スコア:3, 参考になる)

      by deleted user (19654) on 2005年01月24日 0時26分 (#683347) ホームページ 日記
      タレコミに「NetBSD や OpenBSD、DragonFlyBSD との比較」
      とありますが、インタビューを受けた FreeBSD の人は
      「OpenBSD のことは知らない」としか言っておらず、
      OpenBSD の SMP とは比較してませんね。

      以前の OnLamp の記事で OpenBSD の人は、
      (セキュリティのために) 最も実装が簡単なビッグロックを
      使っていると言っていたはずです。珍しく謙遜に、
      「うちの SMP は *BSD で一番ダメかも」と言っていたような。

      FreeBSD 側で、
      唯一ジャイアントロックなしで動かせるパケットフィルタとして
      PF を挙げているのは少し皮肉な気がしました。
      まあ PF は既にみんなのものですが。
      シェア
      親コメント

    • Re:スピンロックとスリープロック (スコア:1, 興味深い)

      by Anonymous Coward on 2005年01月23日 19時14分 (#683223)
      以前話題になっていた遺伝的アルゴリズムでカーネルチューニング [srad.jp]みたく、チューニングによって、それぞれのロックを使い分けるみたいな事はできないのかな？
      シェア
      親コメント

      • Re:スピンロックとスリープロック (スコア:2, 参考になる)

        by ef (25263) on 2005年01月23日 21時56分 (#683283)
        チューニングによって、それぞれのロックを使い分けるみたいな事はできないのかな？

        linux/Solaris/AIX には lockstat(1M) と言うのがあり、ロックに関する統計情報を集めることは既にできるので、これを使ってスピンからスリープに遷移する閾値をチューニングとかは出来そうですね。

        シェア
        親コメント

  • シングルCPUは、それ用にコンパイルしたカーネルを (スコア:0)

    by Anonymous Coward on 2005年01月24日 11時29分 (#683452)
    走らせた方が、マルチな人もそうでない人も幸せになりそうな気がするのですけど、やっぱり「負け」なんでしょうか？

    • GENERIC カーネル (スコア:1)

      by tag (10007) on 2005年01月24日 13時46分 (#683515) 日記
      インストール用CD-ROMで GENERIC カーネルがインストールされると、 最近はそのまま使うことが多くなりました。以前は、不要なドライバ をはずしたり、IRQ を調整したりするために、必ずカーネルを再構築 したものですが、今はわざわざそれをする必要を感じないのです。 せいぜい、IPFW を有効にする時ぐらいしか GENERIC を変更しません。

      とすると、GENERIC のデフォルトを何にするかが問題です。UP だけ のサポートをデフォルトにして、SMP を有効にしたい場合は必ず カーネル再構築を要求するのでしょうか。それとも、SMP は有効に しておいて、UP 最適化を望む時のみ再構築するのでしょうか。

      インストール途中で、デフォルトでは SMP だけど、ここで UP 専用 と指定すれば、CD-ROM内に準備した専用カーネルをインストールし ます、というような処理が一番親切なのかもしれませんが。

      シェア
      親コメント

      • Re:GENERIC カーネル (スコア:1, 興味深い)

        by Anonymous Coward on 2005年01月24日 20時13分 (#683692)
        >> インストール途中で、デフォルトでは SMP だけど、ここで UP 専用と指定すれば、CD-ROM内に準備した専用カーネルをインストールします、というような処理が一番親切なのかもしれませんが。

        XPは知りませんが、Windows2000の場合は、インストーラがSMPとACPIについては自動認識して、専用のカーネルを入れてくれますね。BIOS設定でACPIをoffにしてたのを忘れてインストールをしてしまい、（インストール後には切り替えられないので）後で泣く泣く再インストールをしたこともあります。

        ド素人の予想ですが、FreeBSDなどの場合は「UP/SMPそれぞれでチューンするには人材リソースが少ない」とか「理論上、どちらでもパフォーマンスがそこそこ（専用カーネルほどではなくても、それに近いレベルで）出せるはずだ」という思想とかじゃないでしょうかね？LinusがHDDのraw deviceの実装を嫌がってたのも、後者と同様の理由でしたよね。

        このあたり、例えばSolarisはどうなってるんでしょうか？
        シェア
        親コメント

        • Re:GENERIC カーネル (スコア:1, 参考になる)

          by Anonymous Coward on 2005年01月26日 10時36分 (#684509)
          >インストール後には切り替えられないので

          デバイスマネージャから「コンピュータ」を選び、その中にあるACPIユニプロセッサ」とか「標準PC」とか表示されているアイコンのプロパティを開き、「ドライバ」タブに切り替えて「ドライバの更新」を選び、「ハードウェアデバイスドライバのインストール」ページ進み、「このデバイスの既知のドライバを表示して、その一覧から選択する」を選んで先に進んで、入れたいドライバを選択すれば、HALやKernelなど、必要な数本のファイルを入れ替えることができますよ。

          シェア
          親コメント

      • Re:GENERIC カーネル (スコア:0)

        by Anonymous Coward
        #683452 ですー

        UP/SMP 環境それぞれに特化したカーネルを用意して、ブート時に
        UP/SMP 環境を判断して、適切な方のカーネルをロードするとか…
        駄目？

        # 非力なマシンを使ってる人には顰蹙ですね。
        # 頭数が増減する事は滅多にない筈だから、カーネルを２つ置く分、

        • Re:GENERIC カーネル (スコア:0)

          by Anonymous Coward
          ipfw への対応とかも含めて、究極的には全部モジュールになってしまえばいいと思うんですけど、
          その辺どうなんでしょうかね。
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人