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 はスピンロックを使っているが、それは非常に短時間に
ロックが解放される時だけである。これは効率性を重んじている
からである。ロックが時間的に最小限の間だけ保持されるなら、
タスクを切り換えるよりも、待つ方がより効率的であるからである。
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.
スピンロックとスリープロック (スコア:4, 参考になる)
- きわめて短時間しか保持されないロックの場合は、スピン・ロックが適している。スピン・ロックにより、待ち状態のスレッドはそのプロセッサを保持し、ロックが使用可能になるまで緊密なループ (スピン) 内でロック・ビットを繰り返し調べることができます。 スピンの結果、CPU 時間が増加します (カーネルまたはカーネル・エクステンション・ロックのシステム時間)。
- 長時間保持されるロックの場合は、スリープ・ロックが適している。スレッドはロックが解除されるまでスリープ状態に入り、ロックが使用可能になると実行待ち行列に戻されます。スリープの結果、アイドル時間が長くなります。
本家では以下のようなコメントがありました。 一方、OSNewsには、以下のようなコメントがありました。 このあたり、どういう戦略が一番有効なのかは、状況に応じた データを準備して、実際に計測してみるしかないようです。 用途によって、全然違う結果が出ることも考えられると思います。OpenBSD との比較 (スコア:3, 参考になる)
とありますが、インタビューを受けた FreeBSD の人は
「OpenBSD のことは知らない」としか言っておらず、
OpenBSD の SMP とは比較してませんね。
以前の OnLamp の記事で OpenBSD の人は、
(セキュリティのために) 最も実装が簡単なビッグロックを
使っていると言っていたはずです。珍しく謙遜に、
「うちの SMP は *BSD で一番ダメかも」と言っていたような。
FreeBSD 側で、
唯一ジャイアントロックなしで動かせるパケットフィルタとして
PF を挙げているのは少し皮肉な気がしました。
まあ PF は既にみんなのものですが。
Re:スピンロックとスリープロック (スコア:1, 興味深い)
Re:スピンロックとスリープロック (スコア:2, 参考になる)
linux/Solaris/AIX には lockstat(1M) と言うのがあり、ロックに関する統計情報を集めることは既にできるので、これを使ってスピンからスリープに遷移する閾値をチューニングとかは出来そうですね。