为什么Numactl内存绑定对代码段不起作用

存储
通常这种有利于全世界,而不利于自己的KPI的事情,是没有多少工程师愿意投入的 :-) 细思恐极,这需要极大的耐心、投入和奉献精神。

[[397751]]

numactl内存绑定中代码段的问题

在一个典型的NUMA架构Linux服务器中,我们常常使用类似

  1. 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 ./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呢?我这里还是打个嘴炮就好,把想象空间留给读者。

本文转载自微信公众号「Linux阅码场」,可以通过以下二维码关注。转载本文请联系Linux阅码场公众号。

 

责任编辑:武晓燕 来源: Linux阅码场
相关推荐

2020-05-26 15:53:01

StraceDocker容器

2021-06-08 08:52:18

Makefile编译c 文件

2021-04-06 11:46:18

比特币加密货币资产

2019-05-07 14:03:53

鼠标中键Windows 10Windows

2018-11-20 13:52:54

2022-12-01 08:09:05

SQLOracleSPM

2023-03-20 09:42:06

2019-07-11 10:30:58

USBWindows 10 快速修复

2018-07-20 10:50:43

WindowsWindows 10Shift

2021-09-08 17:27:54

神经网络AI算法

2019-03-13 10:45:21

凭据Windows 10远程桌面

2021-07-14 07:55:47

Linux CPULinux 系统

2016-12-06 10:30:39

JavaScriptWriteWriteln

2022-12-27 14:43:15

模型GPT

2009-09-22 11:24:07

Hibernate查询

2016-05-26 12:11:00

Redis内存开源

2021-04-16 20:47:42

Go 指令函数

2019-09-24 15:29:57

程序员开发数据

2022-05-11 23:39:21

加密货币区块链智能合约

2021-08-10 09:58:59

ThreadLocal内存泄漏
点赞
收藏

51CTO技术栈公众号