Linux 內核101：NUMA下的競爭管理

本文參考瞭如下這篇論文：

• A Case for NUMA-aware Contention Management on Multicore Systems 直接點擊連接就能夠下載

回顧一下上篇文章

上一篇文章 簡單地介紹了一下多 CPU 下的 NUMA 架構。NUMA 架構中將內存劃分爲多個不一樣的區域，將CPU 和臨近的內存組成一個 node 節點，OS 調度的時候會優先使用臨近的內存，從而解決了以前 UMA 架構下 BUS 帶來的性能問題（由於多個 CPU 會對這一條總線產生競爭）。同時也講到了在MySQL在 NUMA 架構下遇到的 「swap insanity」問題，也就是當MySQL 佔用的內存超過 (100 / node 總數) % 時，因爲『優先使用臨近內存』這個調度模式的存在，形成了內存分配不均，致使系統總體內存充足的狀況下，依然出現大量『不正常』的的 swap 現象。以下圖所示：

本文內容歸納

本文將從『資源競爭管理』的角度切入，將會看到UMA 時代的競爭管理算法將再也不適用於 NUMA，並給出具體的緣由分析和解決方案。看完以後相信你必定會對 NUMA有更加深入的理解，並對多CPU 時代的編程有個感性的認識。

UMA 競爭管理算法對 NUMA 不適用

有共享資源的地方，就會有競爭。有競爭，就會有性能損失。

一直以來，多核系統的共享資源競爭都是一個大問題。內核之間互相競爭共享資源，好比 last-level cache（LLC）、系統請求隊列和內存管理器等。目前比較流行的解決方案叫作 contention-aware scheduler（競爭感知調度程序，下面簡稱爲 CAS），也就是說它可以區分在互相競爭共享資源的 threads，而後把他們分開到不一樣的 domain。有數據顯示，這種調度方法能夠提升最壞狀況下80%、平均10%的性能。

這種算法在 UMA 中是有效的。可是須要考慮到的是， NUMA 相比 UMA 有一點很大的不一樣，那就是 UMA 只有一個 memory node，配備一個 memory controller；而 NUMA中 每一個 node 裏面都有一個 memory node，各自配備了一個 memory controller，以下圖所示：16個核被分爲了4個 node，每一個 node 有一個獨立的 memory（固然每一個核均可以訪問任意位置的內存）。

那麼這種調度方式到底起不起做用呢？若是隻是簡單的想一下的話，也許會以爲爲何不行呢？若是同一個 node 裏面的 threads 競爭特別激烈，那我就把其中一個移到另外一個 node 上，雖說這會帶來必定的延遲，可是競爭就解決了啊。

而後，事情沒那麼簡單，一切真理都來自於實踐，實踐發現，在 NUMA 上面實施這種調度算法的時候，非但沒能很好地解決競爭，反而性能降低了30%。至於緣由，下文將會給出。

爲何不適用？

在 NUMA 架構下，CAS 會感知有哪些相互競爭的 threads，而後把其中一個移到不一樣的 domain 中。這會致使一種狀況：thread的內存沒有分配在該thread 運行的那個 node 裏面，好比說上圖中，一個 thread 原本運行在 c1上，以後因爲競爭被移到 c5上了，可是它的 memory 還在 M1。咱們把這種因爲移動 thread，致使 thread 和它的內存分家的行爲稱做『NUMA-agnostic migrations』（agnostic 中文意思是不可知，自已意會一下~）。

NUMA-agnostic migrations致使了一些問題，比較明顯一點的是thread 獲取內存的延遲提升了，不過這還不是關鍵。更重要的是，NUMA-agnostic migrations沒法緩解一些關鍵資源（memory controller）的競爭問題，甚至還引發對更多資源（interconnect connection）的競爭。

下面這張圖很重要，請仔細看：

解釋一下：T 和 C 分別表示兩個程序（thread）

• 圖0：兩個程序相安無事，沒有競爭關係。
• 圖1：CT 的內存在一個 node，對 memory controller（MC） 產生了競爭關係。（應該還有訪問延遲，圖中可能忘記標註了）
• 圖2： 兩個程序都須要試用進行CPU 之間的快速通道，產生了interconnect connection（IC）競爭。同時還有訪問遠程 memory 帶來的訪問延遲（RL）。
• 圖3：memory controller （MC）競爭，加上遠程訪問延時（RL）。
• 圖4：TC 位於一個 CPU 裏面，對 last-level cache（CA） 產生競爭關係。
• 圖5：CA + RL
• 圖6：CA + MC
• 圖7：最壞的狀況，CA + MC + IC + MC

實驗發現，圖3的性能降低了110%。緣由在於 threads 仍是在相互競爭 memory controller。NUMA-agnostic migrations在遷移 thread 的時候，頗有可能最後會致使這種狀況出現。

假如如今有兩個threads，A 和 B，A 運行在圖一中的 c1上，B 運行在 c2上，他們之間存在競爭關係（競爭last-level cache）。如今有一個 contention-aware 調度器檢測到了 A 和 B 的競爭關係，因而把 B 移動到 c5上去了，如今A 和 B 再也不競爭 last-level cache 了。事實上在 UMA 系統中這的確是起做用了（雖然對於 memory controller 的競爭仍是存在的）。

可是對於 NUMA，A 和 B 的 memory 還在一個地方，對於 最關鍵資源memory controller 的競爭沒有獲得解決。並且還引來了兩個問題，這兩個問題會嚴重影響 B 的性能。

1. interconnect connection。（這點影響會很嚴重）
2. remote access。

總結一下

NUMA-agnostic migrations沒法提升 甚至還會下降NUMA競爭管理的性能，按照對性能的影響程度排序有：

1. 沒可以解決對 memory controller 的競爭關係（memory 還在原來那個地方）。
2. 引發了額外的 interconnect connection。
3. 引發了額外的 remote access。

原論文中還提到了做者本身研究出的一種解決方案，有興趣的同窗能夠去啃一下原文。

相信你看完了，應該對 NUAM 架構有了一個比較感性的認識了吧。以爲寫的不錯（看在gakki 的情面上）不點個贊鼓勵一下？

廣告時間，歡迎你們關注個人微信公衆號。同時本文同步於 github： github.com/liaochangji…