為什么Numactl內存綁定對代碼段不起作用
numactl內存綁定中代碼段的問題
在一個典型的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
代碼段為啥沒進入指定numa?
原因其實是比較清晰的。上述代碼段對應的內存，在Linux內核中，都屬于有文件背景的頁面，受page cache機制管理。
想象一個場景，如果a.out曾經運行過一次(其實我開機后已經在沒有用numactl綁定內存的情況下，運行過一次a.out，上面的數據是第二次運行a.out的時候采集的)，然后系統也加載了一些動態庫，那么a.out本身的代碼段，庫的代碼段可能進入到了numa節點m，從而在內存命中。接下來，如果我們用numactl -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呢?我這里還是打個嘴炮就好，把想象空間留給讀者。
本文轉載自微信公眾號「Linux閱碼場」，可以通過以下二維碼關注。轉載本文請聯系Linux閱碼場公眾號。
