彷徨えるフジワラ

年がら年中さまよってます

OpenSolaris 勉強会 2011.12

東京 OpenSolaris 勉強会主催の 2011.12 勉強会に参加してきた。

前回に引き続き、Solaris Internals の 9.2.6 から要約の発表やら勝手な掘り下げやら。

実際には、前回の発表後に色々情報提供/追加調査があったので、それらに関する復習からの開始。

『32bit x86 の場合、スタックがアドレス低位に確保されるのは何故か?』という件に関しては、『リンカ (or ELF for 32bit x86) の仕様っぽい』という情報が。

っつーことで、ハードウェアアーキテクチャの都合というよりは、ソフトウェアアーキテクチャの都合っぽい。「ページ境界に注意すれば、スタック位置を変更できるっぽい」という話も。
『thr_create() でのスタック領域確保は MAP_NORESERVE 付きなので、実行時に SIGSGV の可能性がある』という件に関しては、自己紹介中にソースの確認をしていたら、実は『pthread_create@solaris も MAP_NORESERVE でスタック確保』していることが判明。

よくよくソースを確認したら、pthread_create() も内部的には thr_create() と同じロジックを呼び出しているので、pthread_create() 呼び出し元が独自にスタック確保をしない限り、同じ挙動になるという具合。

ぐは!てっきり、pthread_create() は MAP_NORESERVE 無しで確保しているかと思ってた....

実は『MAP_NORESERVE 有無での使い分けなんてしてなかった』という点ではすっきりしたのだけれど、『実行時のスタック確保を保証しない』ってのは安全なんだろうか?メモリ枯渇時の性能劣化を覚悟することはあっても、スワップ不足で SIGSEGV 終了するというのは想定外な気がする。っつーか、僕は 21 世紀の今になるまで、そんな状況は想定してなかったよ!

まぁ、CMT (Chip Multi Threading) などの『スレッド多重度重視』なハードウェアアーキテクチャの方向性と、MAP_NORESERVE 指定のスタック確保で『スレッドあたりのリソース保証量を減らす』という方向性が一致しているね、という考察は前回から変わないのだけれど。

そうそう、帰りがけに、watchpoint の API は "/proc" のオンラインマニュアル ("man proc(4)") に記載されていると教えてもらった。

ひょっとして FEM (File Event Monitoring) も section 4 か?と思ったけど、流石にそう簡単な話では無かった。

とりあえず帰りの電車の中で、usr/src/uts/common/fs/fem.c で定義されている fsem_install() から呼び出し元を手繰ってみると .... portfs (usr/src/uts/common/fs/portfs) とやらに辿り着いた!

ソース中のコメントによると、ファイルアクセス由来のイベント (PORT_SOURCE_FILE) に関しては、port_create(3c) を見るべし!との御託宣が。

あー、やっと見つけた。っつーか、さっさと呼び出し元を手繰っていれば、こんなに引っ張る話でも無かったなぁ。4年近くも宙ぶらりんだったなんて.... まぁ、見つかったので良しとするか。

で、結局今日の進捗は、9.4.1 の途中まで (資料内表記で言うところの 9.4.1/10)。

"Solaris Internals" 枠の次の ZFS ベンチ計測の話は、ざっくりまとめると『OpenIndiana は良く出来た子』ということで(笑)。

発表を聞きつつ onnv ソースを確認したところ、『bzero() による未使用領域の0フィル』などの性能劣化要因となりえる修正と、『(おそらく) スレッド間競合を回避するための、mutex の新設』や『書き出し処理の非同期化』といった性能改善に繋がりそうな修正とが、ぱらぱらと見て取れることから、単純に『新しい版の方が高速』というわけでもないという計測結果は、あながち間違っている訳でも無さそう。

うーむ、なんとか時間を捻り出して、ZFS ソースを読み込んでおきたいなぁ。