Virtual Memory Architecture in SunOS

| | コメント(0) | トラックバック(0)

Proceedings of the Summer 1987 USENIX Technical Conference, Jun, 1987, pp.81-94
UNIX Internalsの解説があいまいなのでreferされた論文読んだ。
やはり、VM周りはカーネルの構造を知る上での、一つの大きな山場だろう。関わる要素が
多いし、HWと密接に関わるので分かりにくい。

この論文ではSunOS4.0でサポートされた新しいVMアーキテクチャについて説明されている。
それまで(SunOS2,3)は、4.2BSDベースのVMを採用していたが、移植性や機能不足といった
問題があった。特に4.2BSDでは、VAXをターゲットとしており、他のプラットホームに
移植する場合は、VAXのメモリ・アーキテクチャをソフトウェアでエミュレートしていたし、
mapped-file I/Oもサポートされていなかった。

この論文のアーキテクチャでは、メモリ・ハンドリングの統一化、多くの機能をユーザランド
で実装可能(SYSV shared memoryとか)、移植性の向上、UNIX環境との整合性などを
達成した。

この論文のアーキテクチャは、後にSVR4に統合され、様々なシステムに影響を与えている。
そのうち暇があったらNetBSDで使われているUVM1999の論文でも読むか。

★全体的な概念:
- page-based systemがベースとなり、その上でsegment-based mechanismが動作している。
segment-based systemをベースにした場合、メモリ使用量的にコンパクトに作れるが、
こっちの方が、"better programming abstraction"。基本的には、上位にsegment-basedを
持ってきても、本質的なsegment-based mechanismのadvantageは失われない。

- virtual memoryは、全ての利用可能な物理的なメモリ資源から構成される。たとえば、
ファイルシステム(local/remote両方)、pools of unnamed memory(private/anonymous storageと
も呼ばれる。processor's primary memoryとswapを示す)、その他のランダムアクセスメモリなど。
- virtual memory内の名前付きオブジェクトは、すべて、UNIX file systemを通して参照可能
だからといって、全てのファイルシステムオブジェクトがvmに入っているわけではない。

- プロセスのaddress spaceは、一つ以上のオブジェクトのaddress space上へのマッピング
によって、定義される。それぞれのmappingはpageサイズにalignされる。address spaceは
単純なpageのvectorとして扱うことができる。

- vm内のオブジェクトはそれぞれ、object address spaceを持っている。これは、それぞれの
オブジェクトに特化したアドレス。たとえば、ファイルオフセットやディスクブロックアドレス等。
memory上にmappingされると、参照時にprocess address spaceからobject addressへ変換される。

- mappingが確立されると、これらのオブジェクトはメモリを通して参照できる。利点は以下の3つ。
1. 効率性: 不必要なコピーが無くなる(syscallでbufferingとか)
2. 簡潔性: read-buffering-writeみたいなことをする必要がない
3. 共有: text領域とか共有データをプロセス間でshareできる

★システムコール
- mmap()関連に変更を加えた。msync()の追加、mremap()の削除。

★internal interfaces
- as layer: (process)address space object(as object)とそのインターフェース
  ・as_alloc(), as_free(), as_dup()
  ・as_map(), as_unmap():内部用mmap()/munmap()
  ・as_setprot(),as_checkprot(): 保護情報の設定、チェック
  ・as_fault(),as_faulta()、フォルトを解決、faulta()は非同期フォルト
  x asオブジェクトは、アドレススペースを構成するmappingを含む。
  x また、hat(hardware address translation)構造体も含む。この構造体は、このアドレス
  スペースに関連したメモリ管理ハードウェアの状態を保持している。
  x それぞれのマッピングは、mapping object manager付オブジェクトとして扱われる。
  これらのmapping objectsをsegmentsと呼び、managerをsegment driverと呼ぶ。

- hat layer
  x メモリ管理ハードウェア資源の確保している状態を表すオブジェクト。
  x hatの操作群はVM systemの外からは見えないが、machine-dependent/independent境界
  を表す

- I/O layer
  x マップされたオブジェクトの物理的なI/O操作を提供する
  x 主に物理的なページフレームをpage-inさせるかpage-outさせるかに使われる
  x また、object managerに「VM systemで使われるsystem-specificなページ抽象化」を、
  「マップされたオブジェクトに使われる表現」にマップする機会を与える。
  例としては、vm systemはpage-sizeをベースとして動作する。一方たとえば、4.2BSD UNIX
  File Systemはdisk blockをベースに操作を行うが、page-sizeと異なる場合がある。たとえば、
  スループットやオーバヘッド軽減のために、ページサイズでない大きさのI/O操作が要求
  される場合がある。そういった場合、うまくやる機会を与える。

トラックバック(0)

このブログ記事を参照しているブログ一覧: Virtual Memory Architecture in SunOS

このブログ記事に対するトラックバックURL: http://www.imaq.net/cgi-bin/mt/mt-tb.cgi/125

コメントする

このブログ記事について

このページは、ImaQが2004年2月24日 10:43に書いたブログ記事です。

ひとつ前のブログ記事は「うざすぎる!!」です。

次のブログ記事は「SunOS Virtual Memory Implementation」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 4.01