numactl內存綁定中代碼段的問題

代碼段為什么沒有進入指定的numa節點

內核內存管理一個改進方向建議

在一個典型的NUMA架構Linux服務器中，我們常常使用類似numactl -N 1 -m 1 。/a.out類似的命令來綁定一定進程的memory，比如上面的例子，進程的memory被綁定到NUMA1。

但是這個時候，我們用numastat命令去查看進程a.out的內存分布，很可能會發現它有少部分內存不在NUMA1：

有極少量0.75MB在NUMA0。這是不是說numactl -m 1沒有起作用呢？瞎猜沒用，眼見為實，我們來調查一下這個在NUMA0的內存屬于進程的哪一部分。

基本上可以看出，有3個地方有位于N0的內存，比如：

開始地址是0x40000的，文件背景為/root/a.out的部分；

開始地址是0x7fb9afc000，文件背景為/lib/aarch64-linux-gnu/libc-2.23.so的部分；

開始地址為0x7fb9c42000，文件背景為/lib/aarch64-linux-gnu/ld-2.23.so的部分。

如果我們進一步探究，會發現上面這三段，都是代碼段：

為什么會這樣呢？看起來numactl -m 《node》對代碼段不起作用？

代碼段為啥沒進入指定numa？

原因其實是比較清晰的。上述代碼段對應的內存，在Linux內核中，都屬于有文件背景的頁面，受page cache機制管理。

想象一個場景，如果a.out曾經運行過一次（其實我開機后已經在沒有用numactl綁定內存的情況下，運行過一次a.out，上面的數據是第二次運行a.out的時候采集的），然后系統也加載了一些動態庫，那么a.out本身的代碼段，庫的代碼段可能進入到了numa節點m，從而在內存命中。接下來，如果我們用numactl -m 《n》 。/a.out去運行a.out并綁定numa節點n，勢必要再次需要a.out的代碼段以及a.out依賴的動態庫的代碼段。但是前一次，這些代碼段都進入了page cache（位于NUMA node m），所以第2次在numa node n運行的時候，其實是命中了numa node m里面的內存。

假設我們運行4個a.out，這4個a.out分別運行于4個不同的numa，然后a.out依賴a.out的代碼段、libx.so代碼段，liby.so代碼段。那么，完全有可能出現下圖的情況，a.out的代碼段位于numa0，libcx.so代碼段位于numa1，liby.so的代碼段位于numa2，這樣4份運行中的a.out，都各自有跨NUMA的代碼段內存訪問，這樣在icache替換的時候，都需要跨NUMA訪問內存。

內核為什么這樣做呢？原因在于，page cache的管理機制是以inode為單位的，每個page inode唯一！一個inode（比如a.out對應的inode）的page cache在內存命中的情況下，內核會直接用這部分page cache。這個page cache，不會為每個NUMA單獨復制一份。從page cache的管理角度來講，這沒有問題。

我們把前面的a.out kill掉，然后drop一次cache，再看a.out的內存分布，發現在node0的部分減少了（0.75-》0.63）

為什么呢？因為我drop掉部分page cache后（echo 3也不可能drop掉全部的所有的代碼段，畢竟這里面很多代碼是“活躍”代碼），我們再運行a.out并綁定numa1的時候，這次這些沒有命中的代碼段page cache，會進入到numa1。

如果我們重啟系統，開機第一次運行a.out就綁定numa1呢？這個時候，我們會看到a.out的代碼段在numa1：

然后我們把a.out kill掉，第二次綁定numa node0運行a.out，會發現這次的a.out的代碼段還是在numa node1而不是node0：

原因是它命中了第一次運行a.out已經進入node1的代碼段page cache。

初戀為什么如此刻骨銘心，你終究還是錯過了那個人，而多少年以后，常常回想起來，你依然淚流滿面？因為，它命中了你的page cache。但是終究，一個人，一生可能不會只運行一次a.out。我們終究也要學會放手，把全部的愛，獻給你身邊與你相濡以沫的那個人。

內存管理的改進方向

2020年8月，我在Linux內核里面提交和合入了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里面的外設申請連續內存的時候，可以申請到本NUMA的近地址內存，而不用跑到遠端去，從而提高I/O的性能：

考慮到代碼段以及其他page cache的跨NUMA特點，這里我想提一個可能性，就是per-numa Page cache。內核可以支持讓關鍵的代碼段，文件背景頁面，在每個NUMA單獨獲得一份page cache：

它的缺點是顯而易見的，page cache可能會用多份內存。它的優點也是顯而易見的，就是代碼段不用跨NUMA了。這屬于典型的以空間換時間！

這個事情行不行得通呢？技術上是行得通的，實踐上，我是不敢做的，因為需要大量的benchmark，加上patch至少得發20，30個版本，前后一兩年至少的。別的不說，宋牧春童鞋的省vmemmap內存的patch已經發到了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的優化，不得至少發個30版？通常這種有利于全世界，而不利于自己的KPI的事情，是沒有多少工程師愿意投入的 ：-） 細思恐極，這需要極大的耐心、投入和奉獻精神。

那么，前期是不是可以從一個小點開始優化呢？我覺得是可能的。

比如a.out本身在numa0運行，kill后再在numa1運行，這個時候，內核感知到a.out獨一份，沒有share的情況，是不是直接在內核態把page cache直接migrate到numa1呢？我這里還是打個嘴炮就好，把想象空間留給讀者。

原文標題：宋寶華：為什么numactl內存綁定對代碼段不起作用

文章出處：【微信公眾號：Linuxer】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq