ATA デバイスとシステムとのデータ通信における、最もプリミティブな I/O 処理を行うデバイスドライバを書いたので、その話をしようと思ったが、ファイルシステムの話をするまでとっておく事にする。

前回プロセススイッチの仕組みの話をしたが、その前に、メモリ管理システムを実装しないと、まともなプロセス設計ができない。
今回は、メモリ管理の話を主にする。

ソースは、
http://sourceforge.jp/projects/onix/
でリポジトリが公開されている。

まず、一般的なプロセスの概論とメモリ管理との関連について述べる。
前回話したように、仮想メモリによって実メモリ空間を仮想メモリ空間にマッピングし、仮想的に実メモリを分割されたページの集合と考える。
なので、カーネルは物理メモリをページ毎に処理をするのが具合がいい。ただし、1 ページのサイズは 2^22(=8MB) なので、これをそのまま利用するには、使い勝手が悪いので、各ページに対して加工処理を行い、プロセスに提供する。

広義におけるオペレーティングシステムは、プロセスを単位とする集合である。カーネルも、システムの旗振り役のプロセスと考る。プロセスがメモリを所望した際カーネルがその要求に応えるのだが、先述したようにカーネルの一部の機能がページに対して加工処理を行って、要求に適合したサイズのメモリ領域をプロセスに渡し、カーネル側でどのプロセスにどれだけのメモリをわたしたのかという帳簿をつける。
ここでは、最終的にプロセスに渡されたメモリ領域を slab (木板) と呼び、これを管理するカーネルの機構をスラブアロケータと呼ぶ。
以降で、onix におけるスラブアロケータの概要について話をする。
 
システムには、複数の種類のスラブが存在し、それぞれの種類のスラブをまとめた集合を "スラブディレクトリ" と呼ぶ。
各ページはスラブディレクトリを持ち、スラブアロケータはページのスラブディレクトリに応じて、ページからスラブが取り出される。スラブサイズは先述した用にスラブディレクトリ毎に異なり、同サイズのスラブを大量に抱えこんだスラブディレクトリもあれば、小さいサイズから大きいサイズまでいろいろな種類のスラブを持ったスラブディレクトリもある。
又、物理アドレス空間において、物理メモリ全体を複数の領域に分割し、分割されたそれぞれの領域ごとに異なる種類のスラブディレクトリを持ったページ配置する。

スラブと連呼しているが、linux におけるそれとは違い、スラブキャッシュにない要求に対して動的にスラブを作成する事はせず、onix では固定長の複数種類のスラブを事前に用意しておき、その中から精査してプロセスに渡す処理を実装した。
多少のフラグメンテーションが起こる事が予想されるが、ハードリソースが豊かな時代では、その程度の事でプロセスが餓死する事は無い。

スラブディレクトリにある各スラブは、スラブディレクトリの管理オブジェクト(以下、スラブディスクリプタ)が持つビットマップによって行われる。各スラブは、ページのオフセットとスラブディスクリプタのビットマップ(*1)のオフセットで、スラブアロケータによって識別される。

*1:実際には、ビットではなく各スラブに対して 1 byte の情報を持たせる。
このようなデータ構造にした場合、ビット演算を行う事を考えれば、各スラブに対して高々数種類の情報しか持たせられない。このときスラブアロケータがあるスラブを見たとき、隣接するスラブがプロセスによって連続的に確保されたものなのかどうかわからない。
先にも述べたように、スラブに対してメモリ要求を行うのはプロセスだけなので、プロセスがメモリ確保を行う度に、どのスラブから何バイト確保したかのリストを作成する事で、プロセス管理機構側からどのスラブが連続的に利用されているのか把握できる。又、linux における逆マッピングの仕組みによって、スラブアロケータ側からも把握できる。