彷徨えるフジワラ

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

OpenSolaris 勉強会 2011.11

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

先週の SCMBootCamp in Tokyo 2 に引き続き、今週も青山の Oracle ビルにフラフラと吸い込まれていく自分。

前回の ZFS Day 2011.10 は、エナメル上皮腫手術の退院から間もなかったこともあって、大事をとって ustream 視聴で済ませていたことから、OpenSolaris 勉強会は久々の感が。

はてなダイアリーでの手術に関するエントリを読まれていた参加者の方々から、お見舞いの言葉を頂きました。ご心配をおかけしました&ありがとうございます。

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

例によって脱線しまくりだったけれど、9.2.6 の直前までの 6.5 ページほど進んだので、今回はいつものペースよりは進んだ気が。と思ったら、今回は図/テーブルで3ページほどあるので、実は 3 ページちょいぐらいしか進んで無いかも? .... orz
今回は特に、発表資料で説明した内容に対して、後のページで説明されている事柄に関する質問が出る、という「先回り祭り」状態(笑)。

時間枠の最後に、9.2.5 のスタック周りの話で盛り上がった mmap(2) の MAP_NORESERVE フラグの話は、実は 9.2.6 で詳細を説明してたりするし....

ちなみに、スタック領域の MAP_NORESERVE に関して、まとめを作成した段階では、svc.confid などの特定のスレッドスタックだけが MAP_NORESERVE 付きで確保されていたことと:

  • pthread_create() は、デフォルトのスタック確保処理あり
  • pthread_attr_init() で初期化した属性領域を使用することで、独自のスタック確保ルーチン(いわゆるコールバック)と差し替えが可能

という pthread の仕様があることから:

MAP_NORESERVE 併用の mmap() を使用したスタック領域が適切なケース (例: svc.confid) でのみ、明示的にスタック確保処理を差し替えて、スレッドを生成

という流れなのかと思っていたのだけれど、次の時間枠の中で、以下のような tweet が。

(@_sunnyone) svc.confid を見たけど NONRESERVE してるっぽいのが見当たらないなぁ

げげ!マジで?ということで慌ててソースを漁ってみると:

  • pthread_create() でのスタック確保用 mmap() は MAP_NORESERVE 無し
  • thr_create() でのスタック確保用 mmap() は問答無用で MAP_NORESERVE 有り

という事実が。しかも、thr_create() のオンラインマニュアルには、MAP_NORESERVE 付きの mmap() でスタック確保する旨が明記されている。

あぁ、どっちの API 体系を使用するかで切り分けているのね > MAP_NORESERVE

※ 実はどちらの API でも、スタック確保は MAP_NORESERVE で実施。詳細は 2011.12 開催の勉強会のエントリ参照。

POSIX のモデルだと、スレッド生成の成功=スタック分の swap 領域の予約完了なので、確実にスレッド上での処理が実行できる (まぁ、ヒープの消費次第だけど...) 一方で、処理が走っていない (= 実際にはスタック分のメモリを消費していない) 状況でも、swap 不足によってスレッド多重度を上げられない可能性が。

MAP_NORESERVE 付きスタックだと、メモリ不足の際にメモリ解放待ちをせずに即プロセス終了となるので、まとめを書いている段階では、「メモリ枯渇時には落ちてしまっても良いようなプロセス」で MAP_NORESERVE スタックを採用しているのかと思ったのだけれど、どちらかというと「やたらスレッド多重度が高いけれど、できればメモリ消費要因となりたくないプロセス」での使用の方が、本来の目的なのかも?

そういう意味では、CMT (Chip Multi Threading) 等でスレッド多重度を上げる方向に舵を切っている SPARC プロセッサが主戦場になりつつある Solaris 的には、MAP_NORESERVE 併用のモデルを明に提供しているのは、確かに辻褄が合っている気がする。

勉強会後の懇親会では、こちらも前回に引き続き相澤氏カーネルトークでひとしきり盛り上がる。

他には、電子書籍ネタとか、Kindle ネタとか、 O'reilly Make ネタとか。