Kanoj Sarcar <kanoj@sgi.com> が Nov 1999 に最初に書きました。
http://oss.sgi.com/projects/numa/ に著者のウェブページがあります。
日本語訳：野本浩一 <hng@ps.ksky.ne.jp>
    校正：中野武雄さん <nakano@apm.seikei.ac.jp>

このファイルの目的は、Linux vm における NUMA 関連のコードに関して、
最新の、最前線からのコメントを、様々な人々に書いてもらうことです。

まず NUMA とは何でしょう？このアーキテクチャでは、あるプロセッサからあ
るメモリ領域 (訳注：NUMA のハードウェアはメモリが数箇所に配置されてい
ます) へのアクセス時間が、そのプロセッサとメモリ領域との「距離」によっ
て異なります。メモリの各領域へのアクセス時間は、数個の cpu から等しく
なります。この cpu の組みはそれぞれ「ノード」と呼ばれます。このような
アーキテクチャでは、カーネルでノード間の通信を最小に抑えることが可能な
ら、有利になります。このための仕組みとしては、カーネルの text とリード
オンリーデータをノード間で複製したり、カーネルの主要部分がメモリ上で必
要とするデータ構造を、全てそのノードのメモリに格納したりするなど、多岐
にわたります。

今のところ、numa サポートの機能は全て、広く分散した、不連続な
物理メモリをいかに効率的に利用するか、ということに集中しています。
したがって、NUMA ではなくても、物理アドレス空間に大きなホールを
持つことができるアーキテクチャなら、同じコードが使えます。
これらすべてのコードは CONFIG_DISCONTIGMEM によってひとまとめに
されています。

移植の初期段階では、bootmem アロケータのコードの NUMA 化が行われました。
これには、情報を全て bootmem_data_t 構造体にカプセル化する手法が
取られました。その後ノードごとのコールがこのアロケータに追加されて
いきました。理論的には、bootmem アロケータを用いるプラットフォームなら
なんでも、 bootmem および mem_map データ構造体を、最適と思われる場所に
配置することが可能です。

各ノードのページ割当てデータ構造体も pg_data_t にカプセル化されて
いきました。bootmem_data_t は、この一部に過ぎません。コードを NUMA
からも通常の UMA プラットフォームからも同じように見えるようにするため、
UMA プラットフォームも静的に割当てられた pg_data_t を持つように
なりました (contig_page_data)。この「同じように見えるようにする」ため、
"numnodes" という変数も、すべてのプラットフォームで定義されています。
今後ベンチマークを行っていくに連れ、より多くの変数、例えば low_on_memory,
nr_free_pages なども pg_data_t の中に NUMA 化するかどうかを決めていく
ことになるでしょう。

現在のところ NUMA を認識するページ割当てコードは、ページ割当てを別々の
ノードにラウンドロビン方式で割り当てていこうとします。これは将来、
NUMA の移植がより成熟すれば、カレントノードからの集中的循環検索
(concentratic circle search) を行うように変更されるでしょう。
alloc_pages_node コールも追加されたので、ドライバからはこのコールを
呼び出せば、NUMA プラットフォームか UMA プラットフォームかを意識
しなくても良くなります。
