理解した気分になる Solaris Internals "Chapter 8: Intruduction to Solaris Memory" 総ざらえ

※(注記) 左右のカーソルキーでもページ繰りができます(但しブラウザ依存)

| || |

<div>理解した気分になる<br/>
Solaris Internals<br/>
"Chapter 8: Intruduction to Solaris Memory"<br/>
総ざらえ</div>
<div>
藤原 克則 &#60;foozy&#64lares.dti.ne.jp>
</div>
----@
<div>更新履歴</div>
<dl>
<dt>2011年07月29日</dt>
<dd>typo 修正/考察コメントの修正/自己紹介の更新</dd>
<dt>2011年06月25日</dt>
<dd>初版公開</dd>
</dl>
----@
<div>自己紹介</div>
<p>藤原 克則 ( FUJIWARA Katsunori )</p>
<p>無職。自称「フリーダムプログラマー」</p>
----@
<div>自己紹介</div>
<p>藤原 克則 ( FUJIWARA Katsunori )</p>
<p>無職。自称「フリーダムプログラマー」</p>
<p>受託開発主体の独立系ソフトウェアハウス数社を経てフリーダム化。</p>
<p>前職で、
HPC ( High Performance Computing ) 系システムのために
Solaris 向けファイルシステムを実装したのを機に、
OpenSolaris 勉強会に参加。</p>
<p>前職では、
本業の合間を縫って、
「<a href="/index.cgi/contrast/http://www.amazon.co.jp/dp/4798021741">入門Mercurial Linux/Windows対応</a>」とか
「<a href="/index.cgi/contrast/http://www.amazon.co.jp/dp/4798029181">俺のコードのどこが悪い?―コードレビューを攻略する40のルール</a>」
といった書籍の執筆や、
技術系ウェブ媒体への<a href="/index.cgi/contrast/http://www.lares.dti.ne.jp/~foozy/fujiguruma/books.html">記事の寄稿</a>といったことも。</p>
<div><a href="/index.cgi/contrast/http://www.amazon.co.jp/dp/4798021741"></a>
<a href="/index.cgi/contrast/http://www.amazon.co.jp/dp/4798029181"></a> </div>
<p><a href="/index.cgi/contrast/http://www.lares.dti.ne.jp/~foozy/index.ja.html">ホームページ</a>以外にも、
はてなダイアリー
(<a href="/index.cgi/contrast/http://d.hatena.ne.jp/flying-foozy/">id:flying-foozy</a>) 
等で情報発信中。
Twitter アカウント
(<a href="/index.cgi/contrast/http://twitter.com/#!/flyingfoozy">@flyingfoozy</a>)
は細々と運用中。</p>
----@
<div>本資料について</div>
<p>本資料は、
"<a href="/index.cgi/contrast/http://www.amazon.co.jp/dp/0131482092">Solaris Internals</a>" の第8章を、
各段落毎に「ワンフレーズ」化すること基本としています。</p>
<p>「ワンフレーズ」化対象の段落を識別するために、
以下のような識別情報表記を使用します。</p>
<blockquote>[{章/節番号}/{通し段落番号}]@p.{ページ番号}</blockquote>
<p>例えば、"<span>[8.7/2]@p.451</span>" は、
以下で始まる
「451 ページに配置されている、8.7 節における第2段落」
を指します。</p>
<blockquote>One of the major advantages of using the VM system to ....
</blockquote>
<p>列挙の各項目も1段落として扱います。
単一の列挙項目が複数の段落から構成されている場合は、
構成要素の段落を、それぞれ個別の段落として扱います。</p>
<p>識別情報の構成要素は、
紙媒体の "Solaris Internals Second Edition" を元にしています。</p>
<p>なお、個人的に興味深いと思った点に関しては、
<span>勝手に掘り下げた話を展開</span>します。</p>
----@
<ul>

</ul>
----@

<div>章概要</div>
<p><span>[8/1]@p.447</span></p>
<p>仮想メモリ機能は、
他の構成要素も影響する物凄く重要な機能なので、
以降で詳細を説明します</p>
----@

<div>8.1 Virtual Memory Primer</div>
<p><span>[8.1/1]@p.447</span> ～
<span>[8.1/4]@p.447</span></p>
<p>仮想記憶(virutual memory: VM) の利点は:</p>
<ul>
<li>ユーザ空間からはRAMの管理への配慮が不要
<li>ユーザ空間からはリニアなメモリイメージにしか見えない
<li>ディスク等の大容量/低速/安価なバックストアを併用することで、
(相対的に)小容量/高速/高価なRAMのサイズ以上のアドレス空間を使用できる
</ul>
<hr/>
<p>個人的には、
ユーザプロセス間、ユーザプロセス～カーネル間で、
アドレス空間が隔離されることによる安全性の向上も、
重要な利点だと思う > 仮想記憶</p>
----@

<div>8.2 Two Levels of Memory</div>
<p><span>[8.2/1]@p.448</span></p>
<p>メモリの利用状況に応じて、
VM 機構がディスク～RAMの間で頑張るので、
ユーザ空間からはメモリ割り当てについて気にする必要はありません</p>
<hr/>
<p>メモリの「2つのレベル」というのは、
「ディスク/RAM」という記憶クラスのこと?
「VM管理下にあるメモリ/ユーザ空間から見えるメモリ」
というビューのこと?</p>
----@

<div>8.3 Memory Sharing and Protection</div>
<p><span>[8.3/1]@p.448</span></p>
<p>SunOS で導入された共有ライブラリの概念を更に進めて、
同一プログラムによる複数プロセス間で、
実行バイナリのメモリイメージも共有出来るようになっています
</p>
<hr/>
<p>共有ライブラリ(shared library)での共有の場合、
同じ物理メモリに対して、
各プロセス毎に異なる仮想アドレスが割り当てられるので、
位置非依存コード (position independent code: PIC) 化が必要。</p>
<p>実行可能プログラムのテキストセグメントの共有は、
プロセス起動時におけるローディングアドレスが固定されているので、
共有ライブラリと比較すれば簡単な筈。</p>
<p>本文では、「データセグメントも共有している」と言わんばかりの勢いだが、
read-only で共有マッピングしておいて、
改変が発生した時点で writable なプライベートマッピングにする、
copy-on-write の事を指しているのかな?
</p>
<p>この辺の話は、
メモリ管理がと統合されている事とも関連が深い筈。</p>
----@
<div>8.3 Memory Sharing and Protection</div>
<p><span>[8.3/2]@p.448</span></p>
<p>ハードウェアによるメモリ管理の支援によって、
アドレス空間外の領域にはアクセスできないようになっています。</p>
<hr/>
<p>個別に複製を保持していた時分は、
単にアドレス空間が分離されているだけで安全だったのだろうけど、
共有ライブラリや、
ファイルキャッシュとの統合、
copy-on-write を利用したプロセス間でのメモリ共有など、
メモリ効率向上のための共有が進むと、
保護機能もある程度充実させないと駄目なのだなぁ。
</p>
----@

<div>8.4 Pages: Units of Physical Memory</div>
<p><span>[8.4/1]@p.448</span></p>
<p>物理メモリ(RAM)は、
バックストア(HDD)中の「ファイル+オフセット」に対して、
ページ単位で関連付けが行われる:
ユーザプロセスのヒープやスタックは swap ファイルと、
通常ファイルは対応するファイルと関連付け</p>
<p><span>[8.4/2]@p.449</span></p>
<p>ダーティーページの再利用は、
内容をバックストアに書き出してから、
クリーンなページの再利用は、
何もせずに再利用すれば良い。</p>
<hr/>
<p>SPARC 系 CPU の最小ページ単位は 8K、
x86 系の最小ページ単位は 4K。</p>
<p>MMU が格納可能な変換エントリ数と、
イマドキのメモリ搭載/消費事情を考えると、
最小ページサイズはちょっと有り得ない気もするが、
ひょっとして、
ダーティー化した際の書き出しコストを気にしている?</p>
----@

<div>8.5 Virtual-to-Physical Translation</div>
<p><span>[8.5/1]@p.449</span></p>
<p>MMU ハードウェアによる
「仮想～物理アドレス変換」は、
ページ単位で実施されます。</p>
<p><span>[8.5/2]@p.450</span></p>
<p>MMU におけるページ単位管理により、
様々な用途(プログラムのテキストセグメントや、ヒープ、スタック等)のメモリ領域を、
1つのアドレス空間に貼り付け(mapping)ています。</p>
----@

<div>8.6 Physical Memory Management: Paging and Swapping</div>
<p><span>[8.6/1]@p.450</span></p>
<p>物理メモリとスワップ領域との間におけるメモリ管理の方針には、
swapping と demand paging という2種類の基本的なものがあります。</p>
<p><span>[8.6/2]@p.450</span></p>
<p>対象プロセス群の全メモリを退避する swapping は、
実装が単純な分、復旧時のパフォーマンスが問題です
(= 全メモリが復旧してからしか、プロセスを再開出来ない為)。
demand paging はページ単位で退避/復旧するので、
メモリの一部が退避されたプロセスも実行継続可能です。</p>
<p><span>[8.6/3]@p.450</span></p>
<p>Solaris は基本 demand paging ですが、
メモリが枯渇してきた場合は swapping も使用します。</p>
----@

<div>8.7 Virtual Memory as a File System Cache</div>
<p><span>[8.7/1]@p.450</span></p>
<p>Solaris VM は、
ファイル I/O とメモリ管理を統合している点で、
別途ディスクキャッシュを用意していた初期の SystemV 系 UNIX とは違います。
</p>
<hr/>
<p>初期の SystemV 系 Unix は兎も角、
現状の Linux や BSD 系 OS と比較した場合はどうなの?
by 業務上のライセンス縛りで Linux ソースを読めないエンジニア</p>
----@
<div>8.7 Virtual Memory as a File System Cache</div>
<p><span>[8.7/2]@p.451</span></p>
<p>ファイルシステムキャッシュの管理が VM 機構に統合されることで、
全ての空きメモリをファイルシステムキャッシュとして使用出来る上に、
「キャッシュ使用量上限のチューニング」
といった不毛な作業から解放されます。</p>
----@
<div>8.7 Virtual Memory as a File System Cache</div>
<p><span>[8.7/3]@p.451 ～ [8.7/7]@p.451</span></p>
<p>Solaris VMの主な機能は:</p>
<ul>
<li>「仮想～物理アドレス変換」の管理
<li>スワップ領域とメモリの間でのやりとりの管理
<li>プロセス間でのメモリ共有の管理
<li>ファイルキャッシュの管理
</ul>
<hr/>
<p>っていうか、ここで書くことか? > まとめ</p>
----@

<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/1]@p.451</span></p>
<p>BSD Unix 由来の Solaris VM 機構ですが、
ファイルと仮想メモリの統合という大きな変更によって、
キャッシュ統合や、
VM 階層構造のモジュール化、
複数プラットフォーム/デバイスにおけるコード共有、
といったものがもたらされました。</p>
<p><span>[8.8/2]@p.451</span></p>
<p>仮想記憶機構には、多くの特徴的な機能が付加されてきました。</p>
----@
<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/3]@p.451</span></p>
<p>旧来の実装では、
ファイルキャッシュによるメモリ消費によって、
通常プロセスの利用可能メモリ量が影響を受けていましたが、
Solaris 8 からは空きメモリのみがキャッシュ用途に使用されるようになりました。
</p>
<p><span>[8.8/4]@p.451</span></p>
<p>64bit アーキテクチャの場合、
物理メモリに恒久的な仮想アドレスを割り当てたままにできるようになりました。</p>
<hr/>
<p>仮想アドレスの割り当て/解放は、
MMU エントリの改変も含む(= オーバヘッドが大きい)ことから、
仮想アドレス割り当ての恒久化は効果がありそう。</p>
<p>複数ページに渡る I/O において、
「仮想アドレス的に連続」が前提だったりすると、
結局独自の仮想アドレスマッピングが必要だったりすることも。</p>
<p>ラージページ化することで、
処理対象エントリ数 (= ページ数) を減少させることで、
性能が向上するケースも有り。</p>
----@
<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/5]@p.452</span></p>
<p>メモリサイズがメガバイト級からテラバイト級に移行しており、
より大きなページサイズが求められています。</p>
<p><span>[8.8/6]@p.452</span></p>
<p>共有メモリでのラージページ使用や、
複数ページサイズの混在利用等が進められています。</p>
<hr/>
<p>HPC 界隈では、メインメモリ 512G ～ なマシンも珍しくなくなってきているので、
OS 側もそれに見合った設計/実装が求められる</p>
<p>いっそ、libc や socket 等の標準的な共有ライブラリは、
全てラージページ化すれば良いのに、
という気がしないでもないが、
読み込み単位の巨大化 ⇒ 性能の劣化を気にしているのかな?
(read-only 共有だからダーティページの書き出しコストは気にしなくて良い筈)</p>
<p>ひょっとしたら、
メモリ共有とラージページ化のバランスを取る上で、
メモリへの共有ライブラリの読み込みの際に、
Hot Spot が複数ページに散在しない
(= Hot Spot が集約されていない状況でラージページ化した場合、
実行頻度が低いコードがメモリを不要に占有してしまうため)
ように、
プロファイル情報ベースで稼動環境毎の再配置、
といった話が今後は出てくるかも?</p>
<p>ちなみに、
関数単位で似たようなこと
(= バイナリ改変による Hot Spot 集約)
をやる機能は、
20 世紀時分は HP だったか DEC が出していた筈。</p>
----@
<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/7]@p.452</span></p>
<p>CPU/メモリの搭載量が増えると、
各ハードウェア要素間の相互連携コストに不均衡が生じる場合があります。</p>
<p><span>[8.8/8]@p.452</span></p>
<p>Solaris 9 以降では、
locality group (lgroup) という概念に基づく
MPO (Memory Placement Optimization) 機能が導入されました。</p>
<hr/>
<p>SUN の SPARC サーバは、
比較的エントリークラス (2 CPU SunFire 等) でも、
複数 CPU パッケージ = NUMA 構成な場合が多いけど、
Fujitsu のサーバは、
相当高額なモデルにならないと、
複数 CPU パッケージでも NUMA 構成に<strong>ならない</strong>のは、
会社の個性という噂が。</p>
<p>64bit x86 系は、
複数 CPU パッケージなら NUMA になるということなので、
当該構成のホスト上で lgrpinfo コマンドで確認を。</p>
<p>最近は、
スケールアウト方向に振るのがトレンドだから、
NUMA 構成で複数 lgroup な構成に触れる機会はあまり無いのかな?
</p>
<p>メモリ割り当て処理等で、
lgroup 横断を意識した処理 (ポリシーの動的切り替え等) とかが散見されて、
なかなか面白い > カーネルソース</p>
<p>例えば、
カーネルページ割り当てを受けるための
<code>page_create_va() @usr/src/uts/common/vm/vm_page.c</code>
を契機とした
<code>page_get_freelist() @usr/src/uts/common/vm/vm_pagelist.c</code>
にかけての処理では、
以下のような lgroup 配慮が含まれている。</p>
<ul>
<li>初期のメモリ割り当て元 lgroup 選択のための
<code>lgrp_mem_choose() @usr/src/uts/common/os/lgrp.c</code> 呼び出し</li>
<li>初期のメモリ割り当て元 lgroup からの割り当てが出来ない場合に、
<code>lgrp_memnode_choose() @usr/src/uts/common/os/lgrp.c</code>
を使った lgroup 一覧の走査</li>
</ul>
----@
<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/9]@p.452</span></p>
<p>稼働中に物理メモリの抜き差しが最大限実施出来るように、
メモリ管理機構が拡張されました。</p>
<p><span>[8.8/10]@p.452</span></p>
<p>ユーザ空間向けのメモリ領域は解放/再配置が可能ですが、
カーネル向けのメモリ領域は、
「カーネルケージ」 (kernel cage) に囚われています。</p>
<p><span>[8.8/11]@p.453</span></p>
<p>物理メモリの容量増減は、
RCM(Resource Configuration Manager) によって提供され、
ユーザ空間でもイベント通知を受理可能です
(Oracle 9 はメモリ容量の増減に対応)</p>
<hr/>
<p>そもそも、
その辺で手に入るハードは稼働中のメモリモジュール挿抜に対応してないのでは?
ラックマウントレベルでもエントリクラスは駄目じゃね?
DTrace とかで実際にイベント伝播のフローとかを追いかけてみたいので、
是非対応ハードを勉強会等の機会に提供して頂きたく(笑) > Oracle 様</p>
<p>[8.8/10]@p.452 は、
個人的にちょっと理解不十分。
「カーネルページがカーネルケージに囚われているのは、
再配置不可だから」と「どれでも任意のメモリボードが抜けるけど、
抜けるのは1つだけ」の掛かり受け関係がイマイチわからん .... orz</p>
----@
<div>8.8 New Features of the Virtual Memory Implementation</div>
<p><span>[8.8/12]@p.452</span></p>
<p>新しいメモリ割り当て実装として、
SMP 構成における各 CPU のキャッシュ等にも配慮した
「Slab Allocator」が採用されました。</p>
<hr/>
<p>複数コア/複数ソケット環境が、
比較的安価になってきているので、
性能的な観点からも、
CPU キャッシュに配慮してくれるのは嬉しい話。</p>
<p>最近は、
SLAB 代替として SL<span>U</span>B なるアロケータもあるらしい
(組み込み向けの簡易版に SL<span>O</span>B
アロケータもある模様)。</p>
<p>なお、ここで言う「SLAB 代替」の SLAB が、
Solaris で言う Slab Allocator を指すのか、
「メモリ切り出し処理」に対する一般名詞としての SLAB を指すのかは不明。
情報求む > 詳しい人</p>
----@
<div>理解した気分になる<br/>
Solaris Internals<br/>
"Chapter 8: Intruduction to Solaris Memory"<br/>
総ざらえ</div>
<div>
藤原 克則 &#60;foozy&#64lares.dti.ne.jp>
</div>
<div>～ END ～</div>