宋寶華：為什么numactl內(nèi)存綁定對代碼段不起作用
[導(dǎo)讀]有極少量0.75MB在NUMA0。這是不是說numactl -m 1沒有起作用呢？
本文目錄
閱讀本文大約需要10分鐘
在一個典型的NUMA架構(gòu)Linux服務(wù)器中，我們常常使用類似
numactl -N 1 -m 1 ./a.out 類似的命令來綁定一定進程的memory，比如上面的例子，進程的memory被綁定到NUMA1。
但是這個時候，我們用numastat命令去查看進程a.out的內(nèi)存分布，很可能會發(fā)現(xiàn)它有少部分內(nèi)存不在NUMA1：
有極少量0.75MB在NUMA0。這是不是說numactl -m 1沒有起作用呢？瞎猜沒用，眼見為實，我們來調(diào)查一下這個在NUMA0的內(nèi)存屬于進程的哪一部分。
基本上可以看出，有3個地方有位于N0的內(nèi)存，比如：
為什么會這樣呢？看起來numactl -m對代碼段不起作用？
代碼段為啥沒進入指定numa？
原因其實是比較清晰的。上述代碼段對應(yīng)的內(nèi)存，在Linux內(nèi)核中，都屬于有文件背景的頁面，受page cache機制管理。
想象一個場景，如果a.out曾經(jīng)運行過一次（其實我開機后已經(jīng)在沒有用numactl綁定內(nèi)存的情況下，運行過一次a.out，上面的數(shù)據(jù)是第二次運行a.out的時候采集的），然后系統(tǒng)也加載了一些動態(tài)庫，那么a.out本身的代碼段，庫的代碼段可能進入到了numa節(jié)點m，從而在內(nèi)存命中。接下來，如果我們用numactl -m./a.out去運行a.out并綁定numa節(jié)點n，勢必要再次需要a.out的代碼段以及a.out依賴的動態(tài)庫的代碼段。但是前一次，這些代碼段都進入了page cache(位于NUMA node m)，所以第2次在numa node n運行的時候，其實是命中了numa node m里面的內(nèi)存。
假設(shè)我們運行4個a.out，這4個a.out分別運行于4個不同的numa，然后a.out依賴a.out的代碼段、libx.so代碼段，liby.so代碼段。那么，完全有可能出現(xiàn)下圖的情況，a.out的代碼段位于numa0，libcx.so代碼段位于numa1，liby.so的代碼段位于numa2，這樣4份運行中的a.out，都各自有跨NUMA的代碼段內(nèi)存訪問，這樣在icache替換的時候，都需要跨NUMA訪問內(nèi)存。
內(nèi)核為什么這樣做呢？原因在于，page cache的管理機制是以inode為單位的，每個page inode唯一！一個inode（比如a.out對應(yīng)的inode）的page cache在內(nèi)存命中的情況下，內(nèi)核會直接用這部分page cache。這個page cache，不會為每個NUMA單獨復(fù)制一份。從page cache的管理角度來講，這沒有問題。
我們把前面的a.out kill掉，然后drop一次cache，再看a.out的內(nèi)存分布，發(fā)現(xiàn)在node0的部分減少了(0.75->0.63)
為什么呢？因為我drop掉部分page cache后（echo 3也不可能drop掉全部的所有的代碼段，畢竟這里面很多代碼是“活躍”代碼），我們再運行a.out并綁定numa1的時候，這次這些沒有命中的代碼段page cache，會進入到numa1。
如果我們重啟系統(tǒng)，開機第一次運行a.out就綁定numa1呢？這個時候，我們會看到a.out的代碼段在numa1：
然后我們把a.out kill掉，第二次綁定numa node0運行a.out，會發(fā)現(xiàn)這次的a.out的代碼段還是在numa node1而不是node0：
原因是它命中了第一次運行a.out已經(jīng)進入node1的代碼段page cache。
初戀為什么如此刻骨銘心，你終究還是錯過了那個人，而多少年以后，常?；叵肫饋恚阋廊粶I流滿面？因為，它命中了你的page cache。但是終究，一個人，一生可能不會只運行一次a.out。我們終究也要學會放手，把全部的愛，獻給你身邊與你相濡以沫的那個人。
內(nèi)存管理的改進方向
2020年8月，我在Linux內(nèi)核里面提交和合入了per-numa CMA的支持：
dma-contiguous: provide the ability to reserve per-numa CMA
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b7176c261cdbc
這樣讓每個NUMA里面的外設(shè)申請連續(xù)內(nèi)存的時候，可以申請到本NUMA的近地址內(nèi)存，而不用跑到遠端去，從而提高I/O的性能：
考慮到代碼段以及其他page cache的跨NUMA特點，這里我想提一個可能性，就是per-numa Page cache。內(nèi)核可以支持讓關(guān)鍵的代碼段，文件背景頁面，在每個NUMA單獨獲得一份page cache：
它的缺點是顯而易見的，page cache可能會用多份內(nèi)存。它的優(yōu)點也是顯而易見的，就是代碼段不用跨NUMA了。這屬于典型的以空間換時間！
這個事情行不行得通呢？技術(shù)上是行得通的，實踐上，我是不敢做的，因為需要大量的benchmark，加上patch至少得發(fā)20,30個版本，前后一兩年至少的。別的不說，宋牧春童鞋的省vmemmap內(nèi)存的patch已經(jīng)發(fā)到了22版。
[PATCH v22 0/9] Free some vmemmap pages of HugeTLB page https://lore.kernel.org/lkml/20210430031352.45379-1-songmuchun@bytedance.com/
要是干這個page cache的優(yōu)化，不得至少發(fā)個30版？通常這種有利于全世界，而不利于自己的KPI的事情，是沒有多少工程師愿意投入的 :-) 細思恐極，這需要極大的耐心、投入和奉獻精神。
那么，前期是不是可以從一個小點開始優(yōu)化呢？我覺得是可能的。
比如a.out本身在numa0運行，kill后再在numa1運行，這個時候，內(nèi)核感知到a.out獨一份，沒有share的情況，是不是直接在內(nèi)核態(tài)把page cache直接migrate到numa1呢？我這里還是打個嘴炮就好，把想象空間留給讀者。
閱讀本文大約需要10分鐘
-
numactl內(nèi)存綁定中代碼段的問題
-
代碼段為什么沒有進入指定的numa節(jié)點
-
內(nèi)核內(nèi)存管理一個改進方向建議
在一個典型的NUMA架構(gòu)Linux服務(wù)器中，我們常常使用類似
numactl -N 1 -m 1 ./a.out 類似的命令來綁定一定進程的memory，比如上面的例子，進程的memory被綁定到NUMA1。
但是這個時候，我們用numastat命令去查看進程a.out的內(nèi)存分布，很可能會發(fā)現(xiàn)它有少部分內(nèi)存不在NUMA1：
有極少量0.75MB在NUMA0。這是不是說numactl -m 1沒有起作用呢？瞎猜沒用，眼見為實，我們來調(diào)查一下這個在NUMA0的內(nèi)存屬于進程的哪一部分。
基本上可以看出，有3個地方有位于N0的內(nèi)存，比如：
-
開始地址是0x40000的，文件背景為/root/a.out的部分；
-
開始地址是0x7fb9afc000，文件背景為/lib/aarch64-linux-gnu/libc-2.23.so的部分；
-
開始地址為0x7fb9c42000，文件背景為/lib/aarch64-linux-gnu/ld-2.23.so的部分。
為什么會這樣呢？看起來numactl -m對代碼段不起作用？
代碼段為啥沒進入指定numa？
原因其實是比較清晰的。上述代碼段對應(yīng)的內(nèi)存，在Linux內(nèi)核中，都屬于有文件背景的頁面，受page cache機制管理。
想象一個場景，如果a.out曾經(jīng)運行過一次（其實我開機后已經(jīng)在沒有用numactl綁定內(nèi)存的情況下，運行過一次a.out，上面的數(shù)據(jù)是第二次運行a.out的時候采集的），然后系統(tǒng)也加載了一些動態(tài)庫，那么a.out本身的代碼段，庫的代碼段可能進入到了numa節(jié)點m，從而在內(nèi)存命中。接下來，如果我們用numactl -m./a.out去運行a.out并綁定numa節(jié)點n，勢必要再次需要a.out的代碼段以及a.out依賴的動態(tài)庫的代碼段。但是前一次，這些代碼段都進入了page cache(位于NUMA node m)，所以第2次在numa node n運行的時候，其實是命中了numa node m里面的內(nèi)存。
假設(shè)我們運行4個a.out，這4個a.out分別運行于4個不同的numa，然后a.out依賴a.out的代碼段、libx.so代碼段，liby.so代碼段。那么，完全有可能出現(xiàn)下圖的情況，a.out的代碼段位于numa0，libcx.so代碼段位于numa1，liby.so的代碼段位于numa2，這樣4份運行中的a.out，都各自有跨NUMA的代碼段內(nèi)存訪問，這樣在icache替換的時候，都需要跨NUMA訪問內(nèi)存。
內(nèi)核為什么這樣做呢？原因在于，page cache的管理機制是以inode為單位的，每個page inode唯一！一個inode（比如a.out對應(yīng)的inode）的page cache在內(nèi)存命中的情況下，內(nèi)核會直接用這部分page cache。這個page cache，不會為每個NUMA單獨復(fù)制一份。從page cache的管理角度來講，這沒有問題。
我們把前面的a.out kill掉，然后drop一次cache，再看a.out的內(nèi)存分布，發(fā)現(xiàn)在node0的部分減少了(0.75->0.63)
為什么呢？因為我drop掉部分page cache后（echo 3也不可能drop掉全部的所有的代碼段，畢竟這里面很多代碼是“活躍”代碼），我們再運行a.out并綁定numa1的時候，這次這些沒有命中的代碼段page cache，會進入到numa1。
如果我們重啟系統(tǒng)，開機第一次運行a.out就綁定numa1呢？這個時候，我們會看到a.out的代碼段在numa1：
然后我們把a.out kill掉，第二次綁定numa node0運行a.out，會發(fā)現(xiàn)這次的a.out的代碼段還是在numa node1而不是node0：
原因是它命中了第一次運行a.out已經(jīng)進入node1的代碼段page cache。
初戀為什么如此刻骨銘心，你終究還是錯過了那個人，而多少年以后，常?；叵肫饋恚阋廊粶I流滿面？因為，它命中了你的page cache。但是終究，一個人，一生可能不會只運行一次a.out。我們終究也要學會放手，把全部的愛，獻給你身邊與你相濡以沫的那個人。
內(nèi)存管理的改進方向
2020年8月，我在Linux內(nèi)核里面提交和合入了per-numa CMA的支持：
dma-contiguous: provide the ability to reserve per-numa CMA
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b7176c261cdbc
這樣讓每個NUMA里面的外設(shè)申請連續(xù)內(nèi)存的時候，可以申請到本NUMA的近地址內(nèi)存，而不用跑到遠端去，從而提高I/O的性能：
考慮到代碼段以及其他page cache的跨NUMA特點，這里我想提一個可能性，就是per-numa Page cache。內(nèi)核可以支持讓關(guān)鍵的代碼段，文件背景頁面，在每個NUMA單獨獲得一份page cache：
它的缺點是顯而易見的，page cache可能會用多份內(nèi)存。它的優(yōu)點也是顯而易見的，就是代碼段不用跨NUMA了。這屬于典型的以空間換時間！
這個事情行不行得通呢？技術(shù)上是行得通的，實踐上，我是不敢做的，因為需要大量的benchmark，加上patch至少得發(fā)20,30個版本，前后一兩年至少的。別的不說，宋牧春童鞋的省vmemmap內(nèi)存的patch已經(jīng)發(fā)到了22版。
[PATCH v22 0/9] Free some vmemmap pages of HugeTLB page https://lore.kernel.org/lkml/20210430031352.45379-1-songmuchun@bytedance.com/
要是干這個page cache的優(yōu)化，不得至少發(fā)個30版？通常這種有利于全世界，而不利于自己的KPI的事情，是沒有多少工程師愿意投入的 :-) 細思恐極，這需要極大的耐心、投入和奉獻精神。
那么，前期是不是可以從一個小點開始優(yōu)化呢？我覺得是可能的。
比如a.out本身在numa0運行，kill后再在numa1運行，這個時候，內(nèi)核感知到a.out獨一份，沒有share的情況，是不是直接在內(nèi)核態(tài)把page cache直接migrate到numa1呢？我這里還是打個嘴炮就好，把想象空間留給讀者。
下載文檔
