教你如何解决DPDK内存大页在NUMA架构重分配问题

在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