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
-
內存
+關注
關注
8文章
3020瀏覽量
74008 -
代碼
+關注
關注
30文章
4780瀏覽量
68535
原文標題:宋寶華:為什么numactl內存綁定對代碼段不起作用
文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論