写真のMMU（パート1）

メモリ管理ユニット（MMU）についてお話します。 もちろん、MMUの主な機能は仮想メモリのハードウェアサポートです。 Academician Glushkovが編集したサイバネティックスの辞書は、仮想メモリは、オペレーティングシステムによってユーザープログラム、その作業フィールド、および情報配列をホストするために割り当てられた仮想メモリであることを示しています。



仮想メモリを備えたシステムには、主に次の4つのプロパティがあります。

1. ユーザープロセスは相互に分離されており、死にかけ、システム全体をドラッグしないでください
2. ユーザープロセスは物理メモリから分離されています。つまり、実際にどのくらいのRAMがあり、どのアドレスにあるかはわかりません。
3. オペレーティングシステムは、仮想メモリのないシステムよりもはるかに複雑です。
4. 次のプロセッサコマンドの実行にかかる時間を事前に知ることはできません。

上記のすべての項目の利点は明らかです：数百万人の曲がりくねったアプリケーションプログラマー、オペレーティングシステムの数千人の開発者、数え切れない数のエンベダーは、彼らがまだビジネスをしているという事実に感謝しています。



残念ながら、何らかの理由で、上記の同志たち全員がMMUについて十分に敬意を払っていません。また、仮想メモリの知識は通常、メモリのページ編成とTranslation Lookaside Buffer（TLB）の研究から始まります。 最も興味深い部分は舞台裏に残っています。



ウィキペディアを繰り返したくないので、ページメモリが何であるかを忘れてしまった場合は、 リンクをたどってみましょう。 TLBについては、以下の行がいくつかあります。

MMUデバイス

それでは、ビジネスに取りかかりましょう。 これは、仮想メモリをサポートしないプロセッサがどのように見えるかです：







そのようなプロセッサのプログラムで使用されるすべてのアドレスは、実際の「物理」アドレスです。 プログラムをリンクするプログラマは、RAMのアドレスを知っている必要があります。 アドレス0x02300000-0x0239FFFFにマップされた640 kBのRAMをはんだ付けした場合、プログラム内のすべてのアドレスがこの領域に分類されます。



プログラマが常に4ギガバイトのメモリを持っていると考えたい場合（もちろん、32ビットプロセッサについて話している）、彼のプログラムがプロセッサをスリープ状態からそらす唯一のものである場合、仮想メモリが必要です。 仮想メモリのサポートを追加するには、プロセッサとRAMの間にMMUを配置するだけで十分です。これにより、仮想アドレス（プログラムで使用されるアドレス）が物理アドレス（メモリチップの入力に送られるアドレス）に変換されます。







この配置は非常に便利です。MMUは、プロセッサがメモリにアクセスするとき（たとえば、キャッシュがミスしたとき）にのみ使用され、残りの時間は使用されずエネルギーを節約します。 また、この場合、MMUはプロセッサのパフォーマンスにほとんど影響しません。



MMUの内部では次のことが行われます。







このプロセスは次のようになります。

1. プロセッサは、MMU入力に仮想アドレスを入力します
2. MMUがオフになっている場合、または仮想アドレスが未変換領域に該当する場合、物理アドレスは単に仮想アドレスと同等になります
3. MMUがオンになっていて、仮想アドレスがブロードキャスト領域に入る場合、アドレスは変換されます。つまり、仮想ページ番号は対応する物理ページの番号に置き換えられます（ページ内のオフセットは同じです）。
   
   
   • 目的の仮想ページ番号を持つレコードがTLBにある場合、物理ページ番号がそこから取得されます
   • TLBに必要なエントリがない場合は、オペレーティングシステムが未変換のRAM領域に配置するページテーブルでそれを探す必要があります（前のミス処理中にTLBミスがないように）。 検索は、ハードウェアとソフトウェアの両方で実装できます-ページフォールトと呼ばれる例外ハンドラーを介して。 見つかったエントリはTLBに追加され、その後、TLBミスの原因となったコマンドが再度実行されます。

簡単な例を使用してTLBを見てみましょう。 2つのプロセスAとBがあるとします。それぞれが独自のアドレス空間に存在し、0〜0xFFFFFFFFのすべてのアドレスが利用可能です。 各プロセスのアドレス空間は256バイトのページに分割されます（この数値は天井から取りました-通常、ページサイズは1キロバイト以上です）。 各プロセスの最初のページのアドレスはゼロ、2番目は0x100、3番目は0x200、というように、最後のページの0xFFFFFF00まで続きます。 もちろん、プロセスは使用可能なすべてのスペースを占有する必要はありません。 この例では、プロセスAは2ページのみを占有し、プロセスBは3ページを占有します。 さらに、ページの1つは両方のプロセスに共通です。



また、256バイトの6ページに分割された1536バイトの物理メモリ（仮想メモリと物理メモリのページサイズは常に同じです）があり、このメモリはアドレス0x40000000からプロセッサの物理アドレススペースにマップされます（これがプロセッサにはんだ付けされた方法です）。







この例では、プロセスAの最初のページは、アドレス0x40000500からの物理メモリにあります。 このページへのアクセス方法については詳しく説明しません。オペレーティングシステムがこのページを読み込むことを知るだけで十分です。 また、彼女は（TLBではなく）ページテーブルにエントリを追加し、この物理ページを対応する仮想ページにリンクし、制御をプロセスに転送します。 プロセスAによって実行される最初のコマンドはTLBミスを引き起こし、その結果、新しいレコードがTLBに追加されます。

プロセスAが2番目のページにアクセスする必要がある場合、オペレーティングシステムはそれを物理メモリの空き領域に読み込みます（0x40000200にします）。 別のTLBミスが発生し、目的のエントリがTLBに再び追加されます。 TLBに場所がない場合、以前のエントリの1つが上書きされます。



その後、オペレーティングシステムはプロセスAを一時停止し、プロセスBを開始できます。最初のページは物理アドレス0x40000000に読み込まれます。 ただし、プロセスAとは異なり、TLBにはゼロ仮想アドレスのエントリが既にあるため、プロセスBの最初のコマンドはTLBミスを引き起こしません。 その結果、プロセスBはプロセスAの処理を開始します！ おもしろいことに、これは、狭い範囲で広く知られているARM9プロセッサが正確に機能した方法です。



この問題を解決する最も簡単な方法は、コンテキストを切り替えるときにTLBを無効にすることです。つまり、TLBのすべてのエントリを無効としてマークします。 次のように、これは良い考えではありません。

• この時点のTLBでは、8つのエントリのうち2つのみが占有されています。つまり、新しいエントリは問題なくそこに収まります。
• TLBから他のプロセスに属するエントリを削除すると、オペレーティングシステムがそれらを再起動したときに、これらのプロセスに強制的に繰り返しページエラーが生成されます。 TLBに8つのエントリではなく、1000のエントリがある場合、システムパフォーマンスが大幅に低下する可能性があります。

より複雑な方法は、すべてのプログラムをリンクして、プロセッサーの仮想アドレス空間の異なる部分を使用するようにすることです。 たとえば、プロセスAが下部（0x0-0x7FFFFFFF）を占有し、プロセスBが最高部（0x80000000-0xFFFFFFFF）を占有する場合があります。 明らかに、この場合、プロセスを互いに分離するという話はありませんが、この方法は組み込みシステムで時々使用されます。 汎用システムの場合、明らかな理由により、適切ではありません。



3番目の方法は、2番目の方法の開発です。 複数のプロセス間で4ギガバイトの仮想プロセッサアドレス空間を共有するのではなく、単に増やしてみませんか？ 256回言う？ また、プロセスを確実に分離するために、すべてのプロセスがまだ4ギガバイトのRAMを使用できるようにしますか？

それは非常にシンプルであることが判明しました。 仮想アドレスは40ビットに拡張され、最上位8ビットはプロセスごとに一意であり、特別なレジスターであるプロセスID（PID）に記録されました。 コンテキストを切り替えると、オペレーティングシステムはPIDを新しい値で上書きします（プロセス自体はPIDを変更できません）。

プロセスAのPIDが1で、プロセスBのPIDが2の場合、プロセスの観点から同じ仮想アドレス、たとえば0x00000100は、プロセッサの観点とは異なることがわかります-それぞれ0x0100000100と0x0200000100。

明らかに、TLBには24ビットではなく、32ビットの仮想ページ番号が含まれているはずです。 便宜上、上位8ビットは別のフィールド（アドレススペースID（ASID））に保存されます。



現在、プロセッサがMMU入力に仮想アドレスを提供すると、VPNとASIDの組み合わせを使用してTLBが検索されるため、プロセスBの最初のコマンドは、TLBの以前の無効化がなくてもページエラーを引き起こします。







最近のプロセッサでは、ASIDはほとんどの場合8ビットまたは16ビットです。 たとえば、ARM11以降のMMUを備えたすべてのARMプロセッサでは、ASIDは8ビットであり、16ビットASIDのサポートがARMv8アーキテクチャに追加されています。



ところで、プロセッサが仮想化をサポートしている場合、ASIDに加えて、プロセッサの仮想アドレス空間をさらに拡張し、その上で実行されている仮想マシンの数を含むVSID（仮想アドレススペースIDentificator）も持つことができます。



ASIDを追加した後でも、1つ以上のレコードまたはTLB全体を無効にする必要がある場合があります。

1. 物理ページがRAMからディスクにアンロードされる場合-このページは完全に異なるアドレスでメモリにロードされるため、仮想アドレスは変更されませんが、物理アドレスは変更されます
2. オペレーティングシステムがプロセスのPIDを変更した場合-ASIDは異なるため
3. オペレーティングシステムがプロセスを完了した場合

これは、1つのニュアンスではないにしても、MMUについての物語を完成させることができます。 実際には、MMUに加えて、プロセッサとRAMの間にキャッシュメモリもあります。



キャッシュメモリとは何か、それがどのように機能するかを忘れた人は、 あちこちで知識を更新できます。



例として、1キロバイトのサイズの2チャネル（2ウェイ）キャッシュを使用し、キャッシュの行（またはキャッシュの行）のサイズを64バイトにします。 コマンドキャッシュ、データキャッシュ、または複合キャッシュのいずれでもかまいません。 メモリページのサイズは256バイトであるため、各ページに4つのキャッシュラインが配置されます。



キャッシュはプロセッサとMMUの間にあるため、仮想アドレスのみがインデックス作成とタグ比較に使用されることは明らかです（物理アドレスはMMUの出力にのみ表示されます）。 英語では、このようなキャッシュは、仮想インデックス付き仮想タグ付きキャッシュ（VIVT）と呼ばれます。

VIVTキャッシュ内のオモニマシャーシ内の寄生虫

実際、問題は何ですか？ 別の例を検討する時が来ました。 同じ2つのプロセスAとBを実行します。

1. プロセスAが最初に実行されると仮定すると、実行中に、このプロセスのコマンドまたはデータを含む行が1つずつキャッシュメモリに読み込まれます（行0〜4）。
2. オペレーティングシステムはプロセスAを停止し、プロセスBに制御を渡します。
3. 理論的には、現時点では、プロセッサはプロセスBの最初のページの最初の行をキャッシュにロードし、そこからコマンドの実行を開始する必要があります。 実際、プロセッサは仮想アドレス0x0をキャッシュ入力に送信します。その後、キャッシュは、目的のラインが既にキャッシュされているため、何もロードする必要がないと応答します。
4. プロセスBは、プロセスAのコードの元気な処理を開始します。

ASIDをTLBに追加することでこの問題を解決しただけですか？ そして、私たちが持っているキャッシュはMMUに任されています-キャッシュミスがなければ、MMUを見ることも、ASIDが何なのかもわかりません。







これはVIVTキャッシュの最初の問題です-同じ仮想アドレスを異なる物理アドレスにマップできる場合のいわゆる同音異義語（この場合、仮想アドレス0x00000000はプロセスAの物理アドレス0x40000500とプロセスBの0x40000000にマップされます）。



同音異義語の問題を解決するための多くのオプションがあります。

1. コンテキストを切り替えるときに、キャッシュを「フラッシュ」し（キャッシュフラッシュ、つまり、キャッシュの変更内容をメモリに書き戻す）、キャッシュを無効にします（つまり、行を無効としてマークします）。 コマンドとデータの個別のキャッシュがある場合、コマンドキャッシュは無効化（つまり、すべての行を空としてマーク）するのに十分単純です。これは、コマンドキャッシュがプロセッサに対して読み取り専用であり、フラッシュする意味がないためです。
2. キャッシュタグにASIDを追加
3. キャッシュにアクセスするたびにMMUに連絡してください。ミスが発生したときだけでなく、既存のロジックを使用してPIDとASIDを比較できます。 さらば、省エネとスピード！

どのオプションが好きですか？ 私はおそらく2番目について考えます。 ARM9およびVIVTキャッシュを備えた他のいくつかのプロセッサでは、3番目のプロセッサが実装されています。

VIVTキャッシュの同義語

キャッシュ内の同音異義語が唯一の問題である場合、プロセッサ開発者は世界で最も幸せな人になります。 2番目の問題があります-複数の仮想アドレスが同じ物理アドレスにマップされるときの同義語、エイリアス。

ramsプロセスAとBに戻りましょう。毎回キャッシュをフラッシュするのは本当に非常に費用がかかるため、同音異義語の問題をある程度解決したとします。

だから：

1. まず、プロセスAが実行されます-ラインA0-A3と一般的なライン0がキャッシュに次々にロードされます（プロセスAとBには1つのページが共通していることを思い出してください）
2. 次に、フラッシュキャッシュではなくオペレーティングシステムがコンテキストを切り替えます
3. プロセスBの実行が開始され、ラインB0〜B7がキャッシュにロードされます。
4. 最後に、プロセスBは共通ライン0を参照します。このラインはプロセスAによってキャッシュに既にロードされていますが、異なる仮想アドレスでキャッシュに表示されるため、プロセッサはそれを認識しません（VIVTキャッシュに物理アドレスがないことを思い出してください）
5. キャッシュミスが発生します。 仮想アドレス0x00000200は物理アドレス0x40000200に変換され、一般回線0がキャッシュにリロードされます。 その場所は仮想アドレスによって決まります-アドレス0x00000200は、インデックス0（ビット8〜6）およびタグ0x1（ビット31〜9）に対応します。
6. インデックス0のセット内の両方のチャネルがすでに占有されているため、すでにロードされている行（A0またはB0）の1つを捨てる必要があります。 LRU（最長時間未使用）アルゴリズムを使用して、キャッシュはラインA0をスローし、代わりに一般ライン0を追加します。

その結果、物理メモリの同じ部分がキャッシュの2つの異なる場所にあります。 ここで、両方のプロセスがコピーを変更し、それをメモリに保持したい場合、そのうちの1つに驚きがあります。

明らかに、この問題はデータキャッシュまたは結合キャッシュ（ここでもコマンドキャッシュは読み取り専用）にのみ関係しますが、同音異義語の問題よりも解決がはるかに困難です。

1. 既にわかった最も簡単な方法は、コンテキストが切り替わるたびにキャッシュをフラッシュすることです（ちなみに、同義語に対抗するには、同音異義語とは異なり、キャッシュを無効にする必要はありません）。 ただし、第1に、高価であり、第2に、プロセスがそのアドレス空間に同じ物理ページの複数のコピーを保持する必要がある場合は役に立ちません。
2. ハードウェアで同義語を特定できます。
   
   
   • または、ミスが発生するたびに、キャッシュ全体を実行し、各タグのアドレスを変換し、受信した物理アドレスと、ミスの原因となったアドレスのブロードキャスト中に受信した物理アドレスを比較します
   • または、逆変換を実行するプロセッサに新しいブロックを追加します-物理アドレスの仮想への変換。 その後、ミスごとに、その原因となったアドレスを変換し、逆変換を使用してこの物理アドレスを仮想に変換し、キャッシュ内のすべてのタグと比較します。 ゴーリーでは、キャッシュをフラッシュする方が良いでしょう！
3. 3番目の方法は、同義語をプログラムで回避することです。 たとえば、共有ページを使用しないでください。 または、プログラムを共有アドレス空間に再度リンクし始めます。

CoherenceおよびVIVTキャッシュ

しかし、それだけではありません！ 私たちは、独自のL1キャッシュを備えたマルチコアプロセッサの時代に生きています。 キャッシュの非一貫性に対処するために、 トリッキーなプロトコルが考案されました。 ただし、これは悪いことです。プロトコルは外部バスを監視し、そのアドレスは何ですか？ 身体的！ そして、キャッシュは仮想のものを使用します。







隣接するプロセッサを待機しているため、どのキャッシュラインをメモリに緊急に書き込む必要があるかをどのようにして見つけるのですか？ ただし、これは別の記事のトピックかもしれません。

VIVTキャッシュの利点

VIVTキャッシュには唯一の重要なプラスがあります。物理ページがメモリからアンロードされる場合、対応するキャッシュラインをフラッシュする必要がありますが、無効にしないでください。 この物理ページがしばらくして別の場所に読み込まれたとしても、VIVTキャッシュにアクセスするときに物理アドレスは使用されず、プロセッサはそれらが変更されたかどうかを気にしないため、キャッシュのコンテンツには反映されません。



約20年前にはさらに多くのプラスがありました。 VIMMキャッシュは、外部MMUが別のチップとして使用されていた当時、積極的に使用されていました。 そのようなMMUへのアクセスは、プロセッサと同じチップにあるMMUへのアクセスよりもはるかに時間がかかりました。 しかし、MMUへのアクセスはキャッシュミスの場合にのみ必要であったため、これにより許容可能なシステムパフォーマンスを確保できました。

どうする

そのため、VIVTキャッシュには、あまりにも多くの欠点といくつかの利点があります（ちなみに、他の罪を忘れた場合-コメントを書いてください）。 賢い人たちは考えて決めました：MMUのキャッシュを転送します。 インデックスとタグは、仮想アドレスではなく物理アドレスから取得します。 そして移動しました。 そして、うまくいったかどうかは、次のパートで学びます。