OSカーネルでのページ管理

私は私の古いOS理論の本をいくつか見ましたが、これらのOSの本すべての明白な欠落の1つは、実際に無料の物理ページ（つまり、実際に無料リストを実装するためのアルゴリズム）を追跡する方法であることに気付きました。ユーザーランドのメモリアロケーターがどのように機能するかはよくわかっていますが、物理ページの割り当てとの大きな違いは、物理ページの断片化は問題にならないということです。隣接しているかどうか。断片化の回避はユーザーランドアロケーターの主要な懸念事項の1つであるため、物理ページの割り当ては基本的に別の問題のようです。TLBへの圧力を減らすためにスーパーページをサポートしたい場合、これは完全に正確ではないと思います。

私の質問：この問題のために最新の高性能カーネルで使用されている手法は何ですか？また、この問題はNUMAシステムでは著しく複雑になりますか？

ページフレームの管理は、概念的には非常に単純です。本当に必要なのはリンクされたリストだけです。ただし、物事を複雑にする2つの主な要因があります。

• DMA。DMAは、1ページのサイズよりも大きな物理バッファーが必要になる可能性がある数少ないものの1つです。さらに、競合するレガシーデバイスがあります。たとえば、x86では、32ビットデバイスは、4Gの制限を下回る物理アドレスからのみDMAを実行できます。ISAの場合はさらに悪化します。
• キャッシュカラーリングは、非常に重要な最適化です。

ほとんどのオペレーティングシステムは、驚くほど単純な手法を使用しています。

たとえば、Windowsは一連のリンクされたリストを使用します（少なくとも、誰かが何かについて言ったときは、少なくともそうでした）。ソースコードが見えないので言うのは難しいですが、おそらくN * Mのリンクされたリストがあります。Nはページが取り得る状態の数です（たとえば、使用中、空き、ページアウト待ち）。 Mは色の数です。

Linuxは、バディアロケーターを使用して物理ページを管理することで有名です。物理ページを考えると、リンクされた一連のリストよりも少しだけ複雑です。

おそらく広範囲にわたって文書化されている最も洗練された管理方式は、Solarisのものです。Bonwick＆Adams、Magazines and Vmem：Extending the Slab Allocator to many CPUs and Arbitrary Resources、USENIX 2001を参照してください。また、本のSolaris Internalsにも詳細な説明があります。Solarisのスラブアロケータは、ロックの競合やキャッシュのスラッシングなどを回避するために多くの問題を抱えており、必要に応じてさまざまなデータ型に合わせて実装を調整することもできます。

興味深いのは、Solarisがスラブアロケーター内にスラブアロケーターをネストすることにより、カーネルオブジェクトの処理に使用するのと同じメモリアロケーターを使用してページフレームを処理することです。この論文は一読の価値があります。