FreeBSDのSMPngについて

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

スピンロックとスリープロック

[tag (10007)]

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 との比較

[deleted user (19654)]

タレコミに「NetBSD や OpenBSD、DragonFlyBSD との比較」
とありますが、インタビューを受けた FreeBSD の人は
「OpenBSD のことは知らない」としか言っておらず、
OpenBSD の SMP とは比較してませんね。

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

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

Re:スピンロックとスリープロック

[Anonymous Coward]

以前話題になっていた遺伝的アルゴリズムでカーネルチューニング [srad.jp]みたく、チューニングによって、それぞれのロックを使い分けるみたいな事はできないのかな？

Re:スピンロックとスリープロック

[ef (25263)]

チューニングによって、それぞれのロックを使い分けるみたいな事はできないのかな？

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

シングルCPUは、それ用にコンパイルしたカーネルを

[Anonymous Coward]

走らせた方が、マルチな人もそうでない人も幸せになりそうな気がするのですけど、やっぱり「負け」なんでしょうか？

GENERIC カーネル

[tag (10007)]

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

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

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

Re:GENERIC カーネル

[Anonymous Coward]

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

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

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

このあたり、例えばSolarisはどうなってるんでしょうか？

Re:GENERIC カーネル

[Anonymous Coward]

>インストール後には切り替えられないので

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

Re:GENERIC カーネル

[Anonymous Coward]

#683452 ですー

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

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

Re:GENERIC カーネル

[Anonymous Coward]

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