OSの起動後メモリ初期化とブートメモリアロケータ

卵が先か：アロケータを作るためのメモリをどう取るか

起動直後のカーネルには根本的な循環があります。物理ページを配るアロケータ（buddy）を立ち上げるには、その管理用データ構造を置くメモリが要る。だが、そのメモリを配るアロケータがまだ無い。 この鶏と卵を断ち切るのが、起動初期だけ使う簡易アロケータ memblock（旧称 bootmem）です。

全体の段取りを1本のタイムラインで押さえます。

ファームウェア（UEFI/BIOS）がメモリマップを構築
  → カーネルが E820 / EFI memory map を読み取る
  → 使用可能領域と予約領域を分類し memblock に登録
  → カーネル本体・initramfs・ページテーブル等を memblock.reserved に予約
  → 各ノード/ゾーンのページフレーム範囲（PFN）を確定
  → struct page 配列（mem_map）を memblock で確保し初期化
  → free_area_init() で buddy のフリーリストを構築
  → mem_init(): 空きページを buddy に投入、memblock を退役
  → 以降の物理ページ割当は alloc_pages（buddy）が担う

物理メモリの上に仮想記憶が立ち上がる流れ全体は ブートチェーンの内部（UEFI・ブートローダ・initramfs） で扱いました。本稿はその「カーネルが制御を受けた直後、メモリ管理が自立するまで」を解剖します。

ファームウェアのメモリマップ：唯一の正

カーネルは自分で DRAM の容量や配置を測りません。どこが使えて、どこが触ってはいけないか は、すべてファームウェアが提供する メモリマップ を正とします。x86 では BIOS の E820（割り込み 15h, AX=E820h で取得）または UEFI の EFI memory map が、アドレス範囲ごとに種別を持つエントリ列を返します。

ここで重要なのは、RAM の物理アドレスは連続とは限らない ことです。MMIO 領域や予約穴があり、マップは「島」が飛び飛びに並ぶ構造になります。この穴の存在こそ、後段で struct page 配列のモデル（後述の sparsemem）が必要になる理由です。

memblock：大粒度で切り出す起動初期アロケータ

memblock は、メモリを アドレス範囲のリスト2本 で管理する素朴なアロケータです。memblock.memory（存在する物理メモリ）と memblock.reserved（既に予約済みの範囲）を持ち、各リストは [開始, サイズ, ノード番号, フラグ] のエントリ配列です。

確保の原理は単純で、memory に含まれ、かつ reserved と重ならない範囲 から要求サイズ分を切り出し、その範囲を reserved に追記するだけです。

memblock_alloc(size, align):
  memblock.memory を走査して空き穴を探す
    （memory にあり reserved に無い区間）
  align 境界に丸めて size 分を確保
  その範囲を memblock.reserved に追加
  起動初期は通例トップダウン（高アドレス側）から取る

buddy のような分割・統合は持ちません。起動初期に確保するものの多くは 解放されない常駐データ（ページテーブル、struct page 配列、初期スラブ等）なので、断片化対策より単純さと、まだ仮想記憶やロック機構が不完全な環境でも動く堅牢さが優先されます。なお初期の確保で重要なのは、カーネル本体・initramfs・展開済みページテーブル・DTB/ACPI テーブル といった「既に物理メモリ上にある中身」を真っ先に reserved へ入れることです。これを忘れると後で上書きされます。

struct page 配列：1物理ページに1つのメタデータ

buddy をはじめカーネルのメモリ管理は、すべての物理ページに対応するメタデータ構造体 struct page を前提とします。各 struct page は参照カウント、フラグ（dirty/locked/LRU 等）、所属するゾーンやスラブ情報などを持ち、物理ページ1枚（典型 4KB）につき1個存在します。物理フレーム番号 PFN（Page Frame Number）= 物理アドレス / ページサイズ が配列添字になり、PFN → struct page と struct page → PFN を相互変換できます。

問題は この配列をどこに、どう置くか です。仮に 64GB の RAM があり 1 個 64 バイトとすると、配列だけで 1GB に達します。これを memblock で確保するのが mem_map の構築です。配置モデルは歴史的に複数あります。

現在の主流は SPARSEMEM です。物理アドレス空間を固定サイズの section に区切り、存在する section にだけ struct page 断片を割り当てます。これにより、物理アドレスが飛び飛び（メモリの「島」が分散）でも、穴の分の配列を無駄に確保せずに済みます。さらに SPARSEMEM_VMEMMAP は、全 struct page があたかも連続配列であるかのような仮想アドレス窓（vmemmap）を用意し、pfn_to_page() を単純な添字計算に落とします。物理が不連続でも、配列アクセスは連続配列同然の速さになるのが要点です。

ノードとゾーン：PFN 範囲の確定

struct page 配列を埋める前に、カーネルは物理メモリを ノード（NUMA ノード） と ゾーン に区切り、それぞれの PFN 範囲を確定します。ノードはメモリの物理的な近接性を表す単位で、NUMA の局所性は NUMAとメモリ局所性 で詳説しています。各ノードの内部はさらにゾーンに分かれます。

ゾーンを分ける根本理由は、デバイスやカーネルがアクセスできるアドレス範囲に制約がある ことです。例えば 32bit までしか扱えない DMA デバイスのために低位ゾーンを温存します。free_area_init() 系の処理が各ノード・ゾーンの開始 PFN と終端 PFN を確定し、ゾーンごとに buddy の フリーリスト（order 0〜10）の空箱 を用意します。この時点ではまだページは投入されておらず、器だけができた状態です。

buddy への引き渡し：memblock の退役

最後の一手が、memblock がまだ自分の reserved に入れていない＝誰も使っていない空きページを、すべて buddy に寄付する 処理です。アーキ依存の mem_init()（および memblock_free_all()）がこれを行います。

mem_init() / memblock_free_all():
  for each region in (memblock.memory - memblock.reserved):
      その範囲の各ページについて:
          struct page を初期化（参照カウント等）
          __free_pages() で buddy のフリーリストへ投入
  集計を totalram_pages 等に反映
  memblock 用のデータ自身も解放し、memblock を以後使わない

ここを境に アロケータの主役が memblock から buddy へ交代 します。投入されたページは order 0 として入り、隣接する buddy 同士は統合（coalesce）されて大きな order のブロックへまとまっていきます。buddy の分割・統合アルゴリズムの詳細は メモリアロケータの内部（buddy systemとslab） を参照してください。以降のカーネル内割当（alloc_pages、その上の slab、さらに上のユーザー空間 malloc）は、すべてこの buddy を底面として積み上がります。

まとめ

• 起動初期は ファームウェアのメモリマップ（E820 / EFI memory map）を唯一の正 とし、使用可能領域と予約領域を分類して memblock に登録する。
• memblock は範囲リスト2本（memory / reserved）で大粒度に切り出す簡易アロケータで、分割・統合を持たず、カーネル本体やページテーブルなど常駐物をまず予約する。
• buddy が必要とする struct page 配列そのもの を memblock で確保・初期化する。穴の多い物理空間に対応するため現主流は SPARSEMEM_VMEMMAP。
• mem_init() で 空きページを buddy のフリーリストへ寄付 し、memblock を退役させる。以降の物理ページ割当はすべて buddy が担う。

ここから上に積み上がる割当層は メモリアロケータの内部（buddy systemとslab）、ページテーブルの構築は 多段ページテーブルの仕組み と合わせて読むと、物理ページの誕生から仮想アドレス変換までが一本につながります。