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的部分。
如果我們進一步探究,會發(fā)現(xiàn)上面這三段,都是代碼段:

為什么會這樣呢?看起來numactl -m 《node》對代碼段不起作用?
代碼段為啥沒進入指定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 《n》 。/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。我們終究也要學(xué)會放手,把全部的愛,獻給你身邊與你相濡以沫的那個人。
內(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呢?我這里還是打個嘴炮就好,把想象空間留給讀者。
原文標題:宋寶華:為什么numactl內(nèi)存綁定對代碼段不起作用
文章出處:【微信公眾號:Linuxer】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
責任編輯:haq
-
內(nèi)存
+關(guān)注
關(guān)注
9文章
3173瀏覽量
76118 -
代碼
+關(guān)注
關(guān)注
30文章
4941瀏覽量
73152
原文標題:宋寶華:為什么numactl內(nèi)存綁定對代碼段不起作用
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
單片機程序的執(zhí)行
匯編程序段的定義介紹
編譯器如何指定代碼的地址段?
時序約束管腳綁定不成功問題
在OpenVINO? C++代碼中啟用 AddressSanitizer 時的內(nèi)存泄漏怎么解決?
飛凌嵌入式ElfBoard ELF 1板卡-uboot編譯鏈接文件uboot.lds
harmony OS NEXT-雙向數(shù)據(jù)綁定MVVM以及$$語法糖介紹
無法在iMX8上啟動gpsd:GPSD綁定怎么解決?
快速搞懂C語言程序內(nèi)存分區(qū)!

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