1.硬體層面解決NUMA

在part2的figure2.3中，

我們瞭解到，在一些機器上，不同的區域訪問特定的記憶體花銷不一樣。例如，CPU1對它專屬的記憶體的訪問速度快於對CPU2專屬記憶體的訪問速度。CPU1訪問CPU2的記憶體需要‘多走路’，這個‘多走的路’叫做NUMA factor。

關於NUMA，這是大型計算機才有的問題。這個大型計算機有很多的CPU訪問同一個記憶體。就像上面的例子。我們使用的個人PC一般不涉及NUMA問題，對記憶體的訪問也都是通過一個北橋走的。對於需要解決NUMA問題的大型計算機，他們是如何設計CPU之間的路徑的？

這是關於CPU連線的拓撲。圖2.3的抽象就是圖5.1中的C=2的情況。
關於解決NUMA問題，很多廠商設計了不同的CPU，在此不表。

更常用的的一種方法是：商用計算機進行組網，通過高速網路相連。但這就不涉及NUMA問題，因為他們並沒有使用共享的地址空間，因而不在討論範圍內。

2.OS層面解決NUMA

我們還可以在軟體層面解決非一致記憶體訪問（NUMA）的問題。
在支援NUMA的機器中，OS必須考慮到記憶體分散這一特性（即不同的cpu有其本地的memory）。例如，在一個CPU中，建立一個程序，給這個程序分配的記憶體應該是當前CPU本地（local）的memory。否則，跨U訪問花銷就大了。當其他的CPU不得不訪問這個程序的記憶體時，那就得多走路了，但OS可以幫忙把這塊記憶體拷貝到其他cpu的記憶體中。但這實現起來也很麻煩。

為了避免情況更糟，一般OS不要把一個節點（CPU的記憶體）的程序或執行緒移動到另一個節點（另一個CPU的記憶體）。否則，處理很麻煩。但作死移了，有兩種解決方案：一是把落腳的記憶體當作暫時的，時機成熟（我也不知道）再移回去。二是移動的時候，儘量移動到和之前物理頁緊鄰的頁上。

由於NUMA,對於程序來說，並不是所有的記憶體都是同等的。有的記憶體都用完了，有的一點兒沒用。解決這個問題，需要在記憶體分配的時候，不要跨U（記憶體）分配，並且把所有記憶體stripe the memory（？）.所有記憶體同等看待。但一個副作用就是，很容易就存在程序跨U（記憶體）移動。對於NUMA不明顯的機器，這種方法可以接受，但並非最優。

上面這種記憶體分配方法是最保守的，是為了不使OS出現致命錯誤。在linux中，os給了每個程序分配記憶體所用何種方法的自由。

3.後續

• 系統關於CPU cache的資訊
• 跨U訪問的花銷

請參考原文 。