JF Linux Kernel 3.x/2.6 Documentation: /usr/src/linux/Documentation/vm/numa

vm/numa

NUMA コードの最新情報 [プレインテキスト版]


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 プラットフォームかを意識
しなくても良くなります。

Linux カーネル 3.x/2.6 付属文書一覧へ戻る