UMAからの脱却 そしてNUMAに入る：“PC”あるいは“Personal Computer”と呼ばれるもの、その変遷を辿る（3/4 ページ）

[大原雄介，ITmedia]

NUMAはなぜなかなか採用されなかったのか

　ただしNUMAの場合、図4のようなメモリの割り当てになってしまった瞬間、極端に性能が落ちることになる。NUMAがなかなか採用されなかったのは、これまでのOSにはNUMAのサポートがないので図4のような動き方をしないようにするための手法がなかった、という部分が大きい。

図4

　NUMAを構成するためには、

1. 複数のメモリコントローラが独立して稼働し、それぞれ異なるメモリアドレスを割り当てる
2. それぞれのメモリコントローラは、図3・図4でいうところのLocal（隣接するCPUからのアクセス）とRemote（お隣のCPUからのInterconnect経由でのアクセス）を区別なく扱う
3. OSは全てのメモリコントローラを独立に管理してやる必要がある。
4. 新しいプロセス（なりタスクなり）を生成する場合は、「なるべく」そのプロセスの稼働するCPUに隣接したメモリコントローラにメモリを割り付ける
5. SuspendしたプロセスをResumeする場合、メモリを再割り当てする場所を意識する

といった配慮が最低限必要になる。

　このうち（1）と（2）は主にハードウェアの問題であってあるが、（3）〜（5）はソフトウェアというかOSの問題である。

　まず（3）。仮想記憶対応OS（Windows系なら一部Windows 3.xとかにも入っていたが、本格的なものはWindows NT系列だろう。UNIX/Linuxは当然仮想記憶対応である）の場合、Page Tableと呼ばれる仕組みで物理メモリと仮想メモリの関係を管理しているが、通常のOSではPage Tableは1カ所にまとめっており、またメモリコントローラが複数ある事は想定されていない。

　ところがNUMAの場合、まずメモリコントローラが複数あるので、これの管理が必要である（割り当てる物理アドレスベースで区別する事も出来なくは無いが、柔軟性に欠ける）。またシステム全体で1つのPage Tableにするのは管理は容易ながら性能へのインパクトがある（図3・4くらいの規模ならそうでもないのだが、それこそメモリコントローラが100個とかあった場合、Page Tableが置かれるメモリコントローラにアクセスが集中してしまうことになる）ため、スケーラビリティを考えるとPage Tableもメモリコントローラ毎に1つずつ用意した方が効果的である。

　次が（4）。プロセスを生成・稼働する際に図４の様な形で動作するのではなく、図３の様に動かすことが望ましいわけで、このためにはSchedulerは「どのCPUでProcessを稼働させる/している」かをきちんと管理する必要があるし、例えば図3でProcess Aが追加のメモリを必要とした際に、それはMemory 1の中で確保されることが好ましく、無条件でMemory 2に新規のメモリを割り当てるようなことはシステムの性能にインパクトを与えてしまう。

　「好ましく」というのは限界があるからで、例えばMemory 1/2がそれぞれ1GBの容量だったとして、今Process Bが1.5GBの容量のメモリを必要としてたら、Memory 1だけでは容量が足りないので、必然的にMemory 2にもある程度のメモリを確保してやる必要がある。もちろん性能的には低下するが、メモリを確保できずにProcessが処理を中止するとか、Page Fileを利用して無理やり動かして性能が激落ちするよりは遥かにマシである。つまりメモリ管理もProcess Schedulerとして連動する仕組みが必要という訳だ。

　最後の（5）は簡単な話で、ProcessがSuspendすると、基本そのProcessはPage FileにSwap outされる形になる（これはWindowsの用語だがLinuxも概ね同じだと思う）。そのProcessが復帰する場合は、Swap fileからProcess Contextを引っ張り出し、新しく確保した物理メモリにその内容をコピーして制御を移すことになる訳だが、NUMAの場合は元々CPU 1で動いていたProcessがSuspend→Resumeされる際にCPU 2に移る、というケースがあり得る。