教你如何解決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個大頁。

然而，問題就來了。對於使用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

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2662218/，如需轉載，請註明出處，否則將追究法律責任。