一. 問題介紹

?在DPDK中往往是在內(nèi)核啟動參數(shù)中設(shè)置要啟動的大頁的總數(shù)量，比如設(shè)置大頁個數(shù)為16個，每個大頁是1G，這樣系統(tǒng)啟動后，就能在/sys/devices/system/node/node0/hugepages/hugepages-1048576KB/nr_hugepages上看到node0上分配的大頁，同樣可以查看到node1上的大頁。默認的情況是內(nèi)核會平均分配到 不同的socket上。在我的機器上，就是2個socket，這樣的話，每個node上會分到8個大頁。

? 然而，問題就來了。對于使用DPDK ring的primary進程和secondary進程而言，為了提高性能，在其中的線程綁core的時候，最好是在同一個socket上，假設(shè)我們綁定了socket 0上的多個core，這時候，無論是primary進程還是secondary進程分配內(nèi)存的時候都是優(yōu)先在socket 0上的node 0分配內(nèi)存，這就導(dǎo)致一個問題，node 1上的內(nèi)存基本就分配不到，也就是說，雖然留出了16G的大頁給DPDK的應(yīng)用使用，但實際上，只有不到一半的使用率。這就有點浪費內(nèi)存咯。

? 急于上面的問題，我們期望能夠重新分配大頁在不同socket上的分配比例，比如，如果DPDK進程都是在socket 0上，那么16G大頁可以分配12G給node 0，剩余的4G給node 1，充分利用內(nèi)存。

二. 重新配置方法

?對于不同的系統(tǒng)，配置的方法大同小異，對于2M的大頁而言，可以直接進行配置，而對于1G的大頁，老些的版本則存在一些問題，如在使用CentOS 6.3時，動態(tài)修改1G大頁的個數(shù)就不成功。

?因此這里只說通用的做法，對于自己的系統(tǒng)，可以再進行細調(diào)。在內(nèi)核啟動參數(shù)中配置大頁的大小和個數(shù)，以Ubuntu為例：

default_hugepagesz=1G hugepagesz=1G hugepages=1設(shè)置到/etc/default/grub中的GRUB_CMDLINE_LINUX中，然后運行update-grub更新啟動參數(shù)配置文件 /boot/grub/grub.cfg。之后重新啟動，cat /proc/meminfo就能看到系統(tǒng)中顯示大頁數(shù)量和剩余的數(shù)量(這個圖是配置的2M的頁)。

接下來就是如何解決提到的背景問題了：

? 在系統(tǒng)啟動后，是可以再進行調(diào)整大頁的數(shù)量的，配置的參數(shù)就在/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages,這個是2M的配置，對于1G的頁，無非就是2048K變?yōu)槠渌怠Ｗ⒁膺@里的node0，如果還有其他socket，就可以調(diào)整對應(yīng)的socket上的大頁的數(shù)量。

? 也正是基于上面的可調(diào)整參數(shù)，可以在系統(tǒng)啟動后，先進行大頁在不同socket上重新調(diào)整，然后再啟動DPDK的應(yīng)用進程。比如共設(shè)置16個大頁，其中node 0上分配12個，node 1上分配4個。這里也會有另一個問題：就是如果調(diào)整后的大頁分配大于原來的總頁數(shù)會怎么樣？對于2M的應(yīng)該沒啥問題，對于1G的，恐怕是不行的，暫時沒實驗，需要注意。這樣調(diào)整后，把DPDK的應(yīng)用都綁定在node 0上對應(yīng)的core（因為我們給他分的大頁多），這樣的話，就能充分利用到我們分配的大頁了。