numactl內(nèi)存綁定中代碼段的問題

代碼段為什么沒有進(jìn)入指定的numa節(jié)點(diǎn)

內(nèi)核內(nèi)存管理一個改進(jìn)方向建議

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

但是這個時候，我們用numastat命令去查看進(jìn)程a.out的內(nèi)存分布，很可能會發(fā)現(xiàn)它有少部分內(nèi)存不在NUMA1：

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

基本上可以看出，有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的部分。

如果我們進(jìn)一步探究，會發(fā)現(xiàn)上面這三段，都是代碼段：

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

代碼段為啥沒進(jìn)入指定numa？

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

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

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

內(nèi)核為什么這樣做呢？原因在于，page cache的管理機(jī)制是以inode為單位的，每個page inode唯一！一個inode（比如a.out對應(yīng)的inode）的page cache在內(nèi)存命中的情況下，內(nèi)核會直接用這部分page cache。這個page cache，不會為每個NUMA單獨(dú)復(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掉全部的所有的代碼段，畢竟這里面很多代碼是“活躍”代碼），我們再運(yùn)行a.out并綁定numa1的時候，這次這些沒有命中的代碼段page cache，會進(jìn)入到numa1。

如果我們重啟系統(tǒng)，開機(jī)第一次運(yùn)行a.out就綁定numa1呢？這個時候，我們會看到a.out的代碼段在numa1：

然后我們把a(bǔ).out kill掉，第二次綁定numa node0運(yùn)行a.out，會發(fā)現(xiàn)這次的a.out的代碼段還是在numa node1而不是node0：

原因是它命中了第一次運(yùn)行a.out已經(jīng)進(jìn)入node1的代碼段page cache。

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

內(nèi)存管理的改進(jìn)方向

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)存，而不用跑到遠(yuǎn)端去，從而提高I/O的性能：

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

它的缺點(diǎn)是顯而易見的，page cache可能會用多份內(nèi)存。它的優(yōu)點(diǎn)也是顯而易見的，就是代碼段不用跨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的事情，是沒有多少工程師愿意投入的 ：-） 細(xì)思恐極，這需要極大的耐心、投入和奉獻(xiàn)精神。

那么，前期是不是可以從一個小點(diǎn)開始優(yōu)化呢？我覺得是可能的。

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

原文標(biāo)題：宋寶華：為什么numactl內(nèi)存綁定對代碼段不起作用

文章出處：【微信公眾號：Linuxer】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq