CPUはRAM内のデータをどう探す？仮想アドレスからDRAMまで

症状への結論：CPUはRAM内のデータを、プログラムのポインターから直接探しているのではありません。仮想アドレスをTLBまたはページ表で物理アドレスへ変換し、キャッシュとメモリーコントローラーを経由して、最終的にDRAMのチャネル、Rank、Bank、行、列を選びます。

最短解法：性能や安全性を調べるときは、アドレスを「仮想アドレス」「物理アドレス」「DRAM内部の位置」に分けて確認してください。DRAMアドレスマッピングはCPUやメモリー構成に依存するため、全機種に共通する固定のビット分割として扱わないことが重要です。

この記事は、仮想アドレスと物理アドレスの違いで混乱している学習者向けです。キャッシュミスやメモリー遅延を分析する性能担当者、ページ表、Rowhammer、仮想化されたアドレス変換を調べる開発者にも役立ちます。

1回のLoad命令で見るアドレスの全体像

例えば、プログラムが次のような読み出しを実行するとします。

value = array[index];

CPUが命令を実行すると、array[index] の計算結果はまず仮想アドレスになります。この段階では、アプリケーションはDRAMチップの場所を指定していません。プロセスに割り当てられたアドレス空間の中で、読み出したい位置を表しているだけです。

OSのページ表は、CPUが使う仮想アドレスを、メモリーシステム側から見える物理アドレスへ対応付けます。プロセスごとにページ表を切り替えられるため、異なるプロセスが同じ仮想アドレスを使っていても、別の物理ページへ対応させられます。ページ表の基本構造は、Linuxカーネルのページ表ドキュメントでも確認できます。

この3層を一つの番地として扱うと、キャッシュミスの原因やRowhammerの調査結果を誤って解釈しやすくなります。

仮想アドレスから物理アドレスへの変換

TLBの命中経路

仮想アドレスは、ページ番号とページ内オフセットに分けて考えられます。TLBには、過去に使われた仮想ページ番号と物理ページフレームの対応が保存されています。

TLBが命中すれば、CPUは仮想ページに対応する物理ページフレームを取得できます。ページ内オフセットは変換されません。ページの大きさが一定なら、仮想アドレスの下位部分はそのまま物理アドレスの下位部分へ引き継がれます。

Intelのアーキテクチャ資料では、毎回ページ表を参照する負担を減らす仕組みとしてTLBが説明されています。Intel 64では複数のページサイズが扱われますが、実際に利用できるサイズや条件はCPUの動作モードとOS設定によって異なります。(Intel Architecture Manuals)

TLB未命中後の処理

TLBが未命中になると、CPUのメモリー管理ユニットはページ表をたどります。多段のページ表では、仮想アドレスの異なるビット範囲を使って上位階層から下位階層へ進み、最終的なページ表エントリーを探します。

Linuxのドキュメントは、ページ表を階層構造として説明しています。対応するアーキテクチャで使わない階層は折りたたまれる場合があるため、すべてのCPUが同じ段数のページ表を使うと考えるのは適切ではありません。

ページ表そのものはメモリー上にありますが、最上位ページ表の場所はアーキテクチャが定めるレジスターなどから取得されます。x86系では、ページングモードに応じた制御レジスターがページ表の起点を示します。そこから各階層のエントリーを参照し、最終的な物理ページフレームを決めます。

注意：TLBミスとページフォルトは同じではありません。TLBミスは変換キャッシュに対応がない状態で、ページ表をたどれば解決できる場合があります。ページフォルトは、ページ表エントリーが無効、またはアクセス権が合わない場合に発生します。

ページフォルトが発生した場合、OSは必要なページを割り当てたり、ファイルやSwapから読み込んだりします。Linuxのメモリー管理資料では、ページフォルトが再試行、メモリー不足、記憶装置からの読み出し、アクセス違反などの理由に分かれることが示されています。(Linux Memory Management API)

物理アドレスが示す範囲

ページフレームとページ内オフセット

物理アドレスが得られると、CPUはメモリーシステムに対して位置を伝えられます。ただし、ここで確定するのは通常、物理アドレス空間上の位置です。DRAMモジュール上の特定チップやセルの位置まで、物理アドレスがそのまま示すわけではありません。

ページサイズが4KBの場合、ページ内オフセットは下位12ビットに相当します。より大きなページを使う場合は、オフセットとして扱われる範囲が変わります。その結果、TLBの利用効率、ページ表参照の回数、キャッシュの局所性にも影響が出ます。実際のページサイズは対象アーキテクチャとOS設定で確認してください。

物理アドレスはRAMチップの位置か

結論は「直接は違う」です。物理アドレスは、メモリーコントローラーが扱うアドレス空間上の番号です。コントローラーはそのビットの一部、または複数ビットの組み合わせを使い、チャネル、Rank、Bank、行、列などを選択します。

DRAM内部は、複数のBankに分かれ、各Bankは行と列を持つ構造として扱われます。ある行を開いて行バッファーへ取り込み、その後に列方向のデータを選ぶため、同じBankで同じ行を続けて使えるかどうかが遅延に影響します。DRAMの行競合とアクセス時間の関係は、DRAMアクセスパターンに関する研究でも扱われています。

ただし、物理アドレスの下位ビットが必ず列、次のビットが必ずBank、上位ビットが必ず行という固定式はありません。メモリーコントローラーは、チャネル間インターリーブやBank分散のためにビットを組み替えたり、複数ビットの組み合わせを利用したりする場合があります。

DRAMアドレスマッピングを調べる研究では、物理アドレスとアクセス遅延の関係から、チャネルやBankの対応を推定します。しかし、その結果を別のCPU世代や異なるメモリー構成へそのまま適用することはできません。(DRAMアドレスマッピング研究)

キャッシュが変える実際のアクセス経路

物理アドレスへの変換が終わっても、毎回DRAMへ行くとは限りません。CPUは通常、複数段のキャッシュを調べます。対象データがL1、L2、または共有ラストレベルキャッシュにあれば、DRAMアクセスは発生しません。

そのため、メモリーアクセスの遅延を測るときは、少なくとも次の3つを分けてください。

• アドレス変換の遅延：TLB命中、TLBミス、ページ表参照
• キャッシュの遅延：L1、L2、LLCの命中またはミス
• 主記憶の遅延：メモリーコントローラーの待ち行列、Bank競合、行の状態

AMDのアーキテクチャ資料でも、キャッシュは空間的局所性を利用して、周辺データをまとめたライン単位でデータを扱う仕組みとして説明されています。1バイトを要求しても、実装上は周辺データを含むキャッシュラインの転送になる場合があります。(AMD64 Architecture Programmer’s Manual)

場面を一つに絞ると、処理は次の順番になります。

1. array[index] の仮想アドレスを計算します。
2. TLBで仮想ページの変換を検索します。
3. TLBが外れたら、CPUがページ表を参照します。
4. 権限が正しければ物理ページフレームを得ます。
5. 物理アドレスを使ってキャッシュを検索します。
6. キャッシュが外れた場合、要求をメモリーコントローラーへ送ります。
7. コントローラーがチャネル、Rank、Bank、行、列を決めます。
8. DRAMから返ったキャッシュラインをCPUへ届けます。

この順序を使うと、アプリケーションの処理が遅いときに、いきなり「RAMが遅い」と決めつけずに済みます。ページ表をたどる負荷、キャッシュの局所性、主記憶の待ち時間を別々に測定できるからです。

経験則：TLBミスが多い処理と、DRAMの行競合が多い処理は、別の対策が必要です。前者はデータ構造やページサイズ、後者はアクセス局所性、並列性、メモリー構成を調べます。

DRAMのチャネル、Rank、Bank、行、列

メモリーコントローラーは、物理アドレスをDRAMの内部構造へ変換します。概念的には、次のような情報へ分解されます。

• チャネル：独立したメモリー経路
• Rank：同時に選択されるDRAMチップ群
• Bank：内部で独立して動作する記憶領域
• 行：Bank内で開かれる行アドレス
• 列：開いた行から読み出す位置

しかし、これらのビット位置を全CPU共通の図にしてはいけません。公開された研究では、物理アドレスからチャネル、Rank、Bank、行、列を推定する手法が扱われていますが、現在のすべてのプラットフォームに同じマッピングが使われていることを意味しません。(DRAMマッピングのリバースエンジニアリング研究)

同じCPU世代でも、DIMMの容量や構成を変えると、インターリーブやアドレス割り当てが変わる可能性があります。RowhammerやDRAMサイドチャネルを調べる場合は、対象マシンで実測し、CPU型番、BIOS設定、メモリー構成、仮想化の有無を記録してください。

仮想化環境で増える変換層

仮想マシンでは、ゲストOSが使う仮想アドレスをゲスト物理アドレスへ変換し、さらにハイパーバイザー側でホスト物理アドレスへ変換する構成があります。二段階ページングでは、ゲスト側のページ表だけを見ても、最終的なDRAM位置は分かりません。

仮想マシン内で確認した物理アドレスを、そのままホストのDRAMアドレスと考えるのは危険です。メモリーの過剰割り当て、ページ共有、仮想NUMA、ホスト側のスケジューリングも、観測結果に影響します。

性能解析で使う判断手順

次の順番で確認すると、調査のやり直しを減らせます。

1. 処理のアドレス範囲を確認する
   ポインターが同じページ内を走査しているのか、多数のページを飛び回っているのかを調べます。

2. ページフォルトを確認する
   ページフォルトが多い場合は、TLBやDRAMより先に、割り当て、ファイル読み込み、Swap、コンテナーのメモリー制限を確認します。

3. TLB関連の事象を分離する
   プロファイラーやCPUの性能カウンターで、TLBミスとキャッシュミスを別々に見ます。

4. キャッシュ局所性を調べる
   配列の走査方向、構造体の配置、ポインター追跡、スレッド間共有を確認します。

5. メモリー帯域と遅延を分ける
   大量の連続転送で遅いのか、ランダムアクセス1回の待ち時間が大きいのかを分けます。

6. DRAMマッピングを必要な場合だけ調べる
   通常のアプリケーション性能調査で、いきなりBankや行の固定式を推定する必要はありません。Rowhammerや特殊な低レベル最適化など、目的が明確な場合に限定します。

7. 対象プラットフォームを固定する
   CPU、メモリー容量、チャネル構成、BIOS、仮想化設定が変わったら、同じマッピングが使えるとは考えないでください。

学習環境へ落とし込む方法

この仕組みを実際の開発環境で確認するなら、まずプロセスの仮想メモリー使用量、ページフォルト、Swap、キャッシュ関連のカウンターを記録します。少なくとも「ページ不足なのか」「キャッシュ局所性が悪いのか」「主記憶帯域が飽和しているのか」を切り分けてから、DRAM内部の推定へ進んでください。

AI Agentやコンパイル処理のように長時間動くタスクでは、搭載メモリー容量だけでは判断できません。運営会社や利用条件を確認する場合は、Kvmzenの会社概要を参照し、実行時間、同時プロセス数、Swapの発生、再現性を同じ条件で記録すると、環境差を比較しやすくなります。

開発用のMac環境を一時的に比較する場合は、CPU性能だけでなく、メモリー使用量、遠隔接続の安定性、長時間タスクの再現性も確認してください。低レベルのアドレス変換を学ぶ目的なら、まず固定した検証環境で再現してから、別のCPUや仮想化環境へ広げるのが安全です。利用可能な環境の概要を確認するときは、Kvmzenの案内ページも確認材料になります。

特定の物理アドレスがどのDRAM行に対応するかを、別の構成へそのまま移植しないでください。CPU型番、メモリー構成、ファームウェア設定が変われば、同じ観測結果にならない可能性があります。

現在の環境とMac環境の選び分け

手元のWindowsやLinux環境は、物理カウンターや低レベルの診断ツールを細かく使える点が利点です。一方で、固定構成の長期運用では、メモリー増設、BIOS設定、冷却、電力、遠隔接続の保守が負担になりやすく、同じ実験環境を短期間だけ再現したい場合には準備コストが増えます。

Mac環境も、CPU内部のDRAMマッピングを自由に解析できる万能な選択肢ではありません。物理アクセスや特定のメモリーコントローラー調査が必要なら、自前の実機を選ぶべきです。ただし、Apple Silicon向けのビルド、Xcode、コンテナー、AI Agentの検証環境を一時的に用意したい場合は、KvmzenのMacレンタルを比較対象にできます。

CPUからDRAMまでの経路を理解したうえで、必要なのが「特定メモリーコントローラーの研究」なのか、「Mac向け開発環境の再現」なのかを分けて選んでください。用途が一時的な検証や遠隔開発なら、購入せずに条件を変えて試せる環境のほうが、構成を固定してから後悔しにくいです。