MMU は、仮想アドレスを物理アドレスに変換する方法を記述したテーブルにアクセスします。 (物理アドレスを仮想アドレスに変換する必要はありません。また、複数の仮想アドレスを介して同じ物理アドレスにアクセスしたり、マップを解除したりできるため、これは一般的に不可能です。) このテーブルのレイアウトは、CPU アーキテクチャに依存します。しかし、一般的な原則は常に同じです。テーブルの物理アドレスを含む CPU レジスタがあり、テーブルの物理アドレスが含まれます (既存のアーキテクチャでは合計 2 ～ 4 レベル)。これには、データが配置されている物理アドレスが含まれています。各レベルで、テーブルのどの要素を使用するかは、仮想アドレスの一部のビットによって決まります。
MMU は、オペレーティング システムのプロセス自体を認識していません。 CPU が別のプロセスの実行に切り替わるとき、つまりコンテキスト スイッチが発生したとき、必要に応じて MMU テーブルを更新するのは、オペレーティング システムのコンテキスト スイッチ コードの仕事です。実際には、すべての Unix システムはプロセスごとにテーブルのコピーをメモリに保持し、現在のプロセスの最上位テーブルを指すように MMU レジスタを更新するだけだと思います。
実際には、オペレーティング システムのプロセスを処理する MMU の一部である TLB があります。 MMU テーブル内のエントリの検索は、複数のメモリ アクセスを伴うため、かなりコストがかかります。 TLB は、これらのルックアップのキャッシュです。コンテキスト スイッチでは、新しいプロセスのマッピングが異なるため、オペレーティング システムは TLB を無効にする (つまり、すべてのキャッシュ エントリを削除する) 必要があります。多くのアーキテクチャでは、OS が各 MMU テーブル エントリにインジケータを配置して、「このエントリはプロセス N に属している」ことを示すことができます。含まれているプロセス番号が現在のプロセス番号でない場合、TLB エントリはスキップされます。 CPU レジスタには現在のプロセス番号が含まれており、コンテキスト スイッチ コードがそれを更新します。このメカニズムは、TLB に一度に複数のプロセスに関する情報を含めることができることを意味します。これにより、これらのプロセス間を行き来する際のパフォーマンスが向上します。多くの場合、すべての OS プロセス ID を格納するのに必要なビットよりも N を格納できるビットの方が少ないため、N はプロセス ID ではなく、この目的のために OS によって生成された番号であり、使用される場合は時間の経過とともに変化します。
Linux では、カーネルは (CPU の能力に関係なく) 3 レベルのページ テーブルを維持します。最上位はページのグローバル ディレクトリで、各プロセスには独自のディレクトリ pgd があります。 mm_struct で .したがって、各プロセスは独自のマッピングを持つことができるため、異なるプロセスのアドレス 12345 は異なる物理アドレスを指します。
CPU は実際にはプロセスを認識していませんが、プロセスをサポートする機能を備えている傾向があります。 x86 スタイルの CPU には、さまざまなタスク関連の機能がありますが、実際には無視される傾向があります。プロセスのスケジューリングはカーネルによって管理されるため、ページ テーブルの変更自体を追跡し、タスクを切り替えるときに新しいプロセスのページ テーブルに切り替えるために必要な CPU の状態を更新できます。 x86 PC では、ページ ディレクトリを指す CR3 制御レジスタを更新する必要があります。
Mel Gorman の Understanding the Linux Virtual Memory Manager のページ テーブル管理の章 本は良い概要を提供します。