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

[大原雄介，ITmedia]

厄介な問題

　いや別にNUMAでなくてもあり得るのだが、厄介なのはその際にはMemory 2に物理メモリを確保してResumeという形を「取った方が良い」ことだ。「取らなければならない」にすると、Memory 2が満杯だった場合にはそのProcessがずーっとResumeできなくなってしまう。

　普通この手の話ではそれぞれのCPUの負荷を見ながら、一番軽いCPUでResumeするという流れになる。ところがNUMAの場合、CPUの負荷とメモリの空き状況を見つつ、場合によってはCPU 2でProcessは動かしつつ、物理メモリはMemory 1を使う、なんてこともあり得る。

　といったあたり。（4）と（5）は根っことしては同じ話だが、要するにNUMA構成においてはOS側でのProcess SchedulerとMemory Managementが結構厄介な話になる。

　もちろんこれを無視して物理的に複数に分かれたメモリコントローラを仮想的に1つのメモリコントローラとしてOSで扱うことは不可能ではない（それこそ0〜1GBはMemory 1、1〜2GBはMemory 2とかにしてしまい、見かけ上2GBのMemoryがある、と扱えばよい）のだが、性能が全然上がらないのは目に見えている。

　厄介なことにこれはハードウェアというよりはソフトウェアの問題であり、OSベンダー側の対応が必要になる。冒頭で「基本的に」UMAが採用されていた、というのは主にハードウェアよりもこのソフトウェア側が理由である。唯一例外があったのは先に触れたSequentのシステムであるが、これは同社が自前でOSまで提供していたから出来た話であり、そもそも構成からしてPentiumを使っていたとは言えPCとは言い難い代物である。そんな訳でPCの世界ではUMA方式が長らく主流であった。

　ついでに書いておくが、SequentのシステムはNUMAではなくccNUMAである。Cache coherency NUMAの略である。要するに図3で言えば、Memory 1とMemory 2は物理的に分離されているから、理想的なシステム、つまりCPU 1はMemory 1だけをアクセスし、CPU 2はMemory 2だけをアクセスする様なシステムであれば、CPU 1のキャッシュはMemory 1だけを対象とし、CPU 2はMemory 2だけを対象とすれば事が足りる。

　ところが上の（4）とか（5）で説明したように、実際にはInterconnect経由でCPU 1からMemory 2やCPU 2からMemory 1をアクセスするという事が起こり得る。

　この場合、自分のLocal Memoryだけをキャッシュ対象にしていると、Interconnectを跨いだ際の性能が激減する。なので、それぞれのCPUは単に自身のLocal Memoryだけではなく、Interconnectを跨いだ先のメモリに対してもキャッシュの対象とする。

　ということは、そのメモリが書き換えられたら、それに応じて処理を行う必要がある訳で、NUMAであってもCache Coherentのプロトコルだけは実装する必要がある。これがccNUMAという訳で、現在は主流の方式になっている。

　さて話を本筋に戻す。

　そのNUMA（というかccNUMA）を最初に実装したのはAMDのOpteronである。これはNorth Bridge機能をCPUに取り込んだ時点でもう明白である。

　Opteronは当初から最大8Pまでの構成を想定しており、4Pならこんな感じ（写真2）、8Pならこうなる（写真3）。

写真2：4P構成。ちなみにOpteronは最大3組のHyperTransport Linkを搭載するので、I/Oの接続を半分に減らして斜め掛けにするという構成も披露されたことがある（が、実装したシステムがあるかどうかまでは知らない）

写真3：8P構成。斜め掛け（Proc 2/5とProc 3/4）のLinkがあるお蔭で、意外に8Pでも平均Hop数は2.7くらいで行けるので、それほど性能は落ちなかったと記憶している。

　物理的にメモリコントローラが4つ/8つに分かれており、これをUMAで実装したらHyperTransport Linkがボトルネックになって性能が上がらないことになる（というか、実際NUMA非対応のOSを使うと性能が上がらなかった）。

　ただMicrosoftはOpteronの投入に合わせてWindows Server 2003でNUMAのサポートを追加しており、これを利用することでこれまでのx86ベースのシステムでは実現できなかったメモリ帯域と、これを生かしたアプリケーション性能を達成した。

　IntelもNehalem世代でこれに追従するようになる。Linuxではこれより早く、2001年11月にリリースされたKernel 2.5でNUMAのサポートが追加されており、このあたりでNUMAの普及に必要となる条件が一応揃ったことになる。

　Desktop向けという意味では、2009年にリリースされたWindows 7では64bit版で論理プロセッサが64個以上だとNUMAと認識される。現在主流のWindows 10とか11もこれに倣っており、Desktop用の論理プロセッサが64個を超えるご家庭用PCではNUMAが有効になるはずだ（*1）。

*1：Professional EditionだとNUMAが有効になるのは確認しているが、Home Editionでも有効になるかどうかは不明である。まぁ誤家庭用PCにHome Editionをインストールすることは普通ないと思うが

　ハードウェアというよりも主にソフトウェアの話であるが、こんな感じでPCもNUMAが一般的に利用されるようになった訳だ。