訳註: これは作業してる最中のもので、本来、訳作業者以外は見えないものです。 訳作業者以外は見ないでください。意味が反対になったりとか当然にあるから、 内容は利用しないでください。 Chapter1.Memory management

Table of Contents

1.1. The UVM virtual memory manager
1.2. Managing wired memory

XXX: この章は極度に不完全です。現在 Chapter2, File system internals を支援するドキュメントがあるけど他はありません。

1.1.The UVM virtual memory manager

UVM は NetBSD の仮想記憶 manager です。

1.1.1.UVM objects

UVM object — あるいは uobj — としても知られる、は、 特有のシステム設備に支えられた 仮想メモリーの隣接する領域です。これはファイルであること (vnode) も可能で、 XXX 他、なに?。

"to be backed by[支えられた]" が意味することを理解するために、 ここでは仮想メモリー管理の幾つかの基礎概念を再考します。 仮想メモリーをサポートするシステムでは、システムは 物理的に利用可能な量より大きなアドレス空間を管理できます。 アドレス空間は固定サイズのチャンク[塊] 、 すなわち ページ(pages) に砕かれ, ページフレーム(page frames) へ分割された物理メモリーとしてです。

システムがメモリーアドレスにアクセスする事が必要になったとき、 ページを見つけた (page hit) か否か (page fault) のどちらかです。 前者の場合、そのページは既にメインメモリーに蓄えられていて、それで、 そのデータは直接アクセスできます。後者の場合、そのページ は現在、メインメモリー上にありません。

page fault が発生すると、プロセッサーのメモリー管理ユニット (MMU) は例外を通じてカーネル に signals し、そして fault を handle するために asks it し: これは、 page fault が解決したか、または、エラーかどちらかの結果になります。 全てのメモリーアクセスが正しい (故にエラーか無い)と仮定すると、カーネルは requested ページを メモリー内に連れてくる必要があります。しかし、 requested ページはどこ? スワップ領域に?ファイルに? ゼロで埋めるべき?

ここが the backing 機構が the game に参加する場所です。 A backing object は、読むべきページおよび たとえあったとしたら変更後に蓄えられるべき場所を定義します。 実装について語ると、 backing object からのページ読み込みは getpages 関数で行われ、 そして、その書き出しは putpages 関数で行われます。

例: 32-bit アドレス空間とみなすと、 4096 bytes のページサイズおよび 仮想アドレス 0x00010000 から開始する 40960 bytes (10 ページ) の uobj; この uobj の backing object は ファイルシステムのテキストファイルを表す vnode です。 ファイルはまだ全く読んでいないと仮定すると、 メインメモリーにはそのページがありません。 さて、ユーザーがオフセット 5000 から、 長さ 4000 で読む事を要求します。このオフセットは、 uobj の2番目の ページに falls し、そして、 ending アドレス (9000) は3番目のページに falls します。 カーネルはこれらの論理オフセットをメモリーアドレス (0x00011388 および 0x00012328)に変換し、そして、その間に含まれる全データを読みます。 それで何が起こったの? MMU は 2つの page faults を起こし、それぞれ vnode の getpages method が呼ばれ、それから 対応するファイルからページを読み、それらをメインメモリー内に置き、 そして caller に制御を戻します。この時点で、 read が供されました。

同様に、連れてきた後、ページはメモリー上で変更でき; 幾つかの点で、 これらの変更は the backing store に flushed する必要になり、 backing object の putpages 操作を生じます。 flush には幾つかの理由があって、 メインメモリーから最近最も使われていないページフレームを reclaim の必要、 uobj を its backing store に 明示的に同期させる (ファイルシステム同期のことを考え)、ファイルのクローズ、 等が含まれます。

1.2.Managing wired memory

NetBSD カーネル が提供する malloc(9) および free(9) 関数 は their ユーザーランド対象物と非常に似ています。それぞれ 割り当てと wired memory の解放です。

1.2.1.Malloc types

Malloc types は、異なる割り当てブロックを 論理 clusters に group するのに使われ、それで、カーネルは もっと効率的な方法で管理できます。

malloc type は静的または動的方式で定義できます。 カーネル構築時にカーネルにリンクするコードの一部に組み込む時は、 Types は静的に定義し; もし standalone モジュールの一部なら動的に定義します。

静的宣言には、 MALLOC_DEFINE(9) マクロが提供されていて、 ソースファイルの global scope な場所で使われます。つぎの signature で:

MALLOC_DEFINE( type,
short_desc,
long_desc);
struct malloc_type *type;
const char *short_desc;
const char *long_desc;

最初のパラメーターは、定義される malloc type の名前で; 上に記された type はあなたを混乱させてはならず、 それは内部事情なのであなたは知るべきではありません。 Malloc types は大抵大文字で 名付けされていて、 M_ で始まります。 一例として、一時データには M_TEMP 、 soft-interrupt 構造体には M_SOFTINTR 、 等。

2番目と3番目のパラメーターは type を描写した character 文字列 で; 前者は短い記述で、後者は長いものを提供します。

動的宣言には、最初にソース中に静的タイプを定義する事が必要です。後に、 malloc_type_attach(9) および malloc_type_detach(9) 関数はカーネルに the type の存在あるいは 除去の通知に使われ; これは大抵、モジュールの 初期化および終了化ルーチン各々で行われます。