教你如何解决DPDK内存大页在NUMA架构重分配问题
在DPDK中往往是在内核启动参数中设置要启动的大页的总数量,比如设置大页个数为16个,每个大页是1G,这样系统启动后,就能在/sys/devices/system/node/node0/hugepages/hugepages-1048576KB/nr_hugepages上看到node0上分配的大页,同样可以查看到node1上的大页。 |
在DPDK中往往是在内核启动参数中设置要启动的大页的总数量,比如设置大页个数为16个,每个大页是1G,这样系统启动后,就能在/sys/devices/system/node/node0/hugepages/hugepages-1048576KB/nr_hugepages上看到node0上分配的大页,同样可以查看到node1上的大页。默认的情况是内核会平均分配到 不同的socket上。在我的机器上,就是2个socket,这样的话,每个node上会分到8个大页。
10年积累的网站设计、做网站经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计后付款的网站建设流程,更有揭西免费网站建设让你可以放心的选择与我们合作。
然而,问题就来了。对于使用DPDK ring的primary进程和secondary进程而言,为了提高性能,在其中的线程绑core的时候,最好是在同一个socket上,假设我们绑定了socket 0上的多个core,这时候,无论是primary进程还是secondary进程分配内存的时候都是优先在socket 0上的node 0分配内存,这就导致一个问题,node 1上的内存基本就分配不到,也就是说,虽然留出了16G的大页给DPDK的应用使用,但实际上,只有不到一半的使用率。这就有点浪费内存咯。
急于上面的问题,我们期望能够重新分配大页在不同socket上的分配比例,比如,如果DPDK进程都是在socket 0上,那么16G大页可以分配12G给node 0,剩余的4G给node 1,充分利用内存。
对于不同的系统,配置的方法大同小异,对于2M的大页而言,可以直接进行配置,而对于1G的大页,老些的版本则存在一些问题,如在使用 CentOS 6.3时,动态修改1G大页的个数就不成功。
因此这里只说通用的做法,对于自己的系统,可以再进行细调。在内核启动参数中配置大页的大小和个数,以Ubuntu为例:
default_hugepagesz=1G hugepagesz=1G hugepages=1设置到/etc/default/grub中的GRUB_CMDLINE_ LINUX中,然后运行update-grub更新启动参数配置文件 /boot/grub/grub.cfg。之后重新启动,cat /proc/meminfo就能看到系统中显示大页数量和剩余的数量(这个图是配置的2M的页)。
接下来就是如何解决提到的背景问题了:
在系统启动后,是可以再进行调整大页的数量的,配置的参数就在/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages,这个是2M的配置,对于1G的页,无非就是2048K变为其他值。注意这里的node0,如果还有其他socket,就可以调整对应的socket上的大页的数量。
也正是基于上面的可调整参数,可以在系统启动后,先进行大页在不同socket上重新调整,然后再启动DPDK的应用进程。比如共设置16个大页,其中node 0上分配12个,node 1上分配4个。这里也会有另一个问题:就是如果调整后的大页分配大于原来的总页数会怎么样?对于2M的应该没啥问题,对于1G的,恐怕是不行的,暂时没实验,需要注意。这样调整后,把DPDK的应用都绑定在node 0上对应的core(因为我们给他分的大页多),这样的话,就能充分利用到我们分配的大页了。
原文地址: https://www.linuxprobe.com/dpdk-numa.html
网站名称:教你如何解决DPDK内存大页在NUMA架构重分配问题
文章来源:http://ybzwz.com/article/jodojh.html