Yes, the expanding of hugepages is more elegant. I  will change it in
the next version.

Matthew Wilcox [off-list ref] 于2021年8月23日周一 上午6:28写道：

On Sun, Aug 22, 2021 at 03:19:52PM -0700, Andrew Morton wrote:

quoted

On Fri, 20 Aug 2021 11:05:36 +0800 yaozhenguo [off-list ref] wrote:

quoted

We can specify the number of hugepages to allocate at boot. But the
hugepages is balanced in all nodes at present. In some scenarios,
we only need hugepags in one node. For example: DPDK needs hugepages
which is in the same node as NIC. if DPDK needs four hugepags of 1G
size in node1 and system has 16 numa nodes. We must reserve 64 hugepags
in kernel cmdline. But, only four hugepages is used. The others should
be free after boot.If the system memory is low(for example: 64G), it will
be an impossible task. So, add hugepages_node kernel parameter to specify
node number of hugepages to allocate at boot.
For example add following parameter:

hugepagesz=1G hugepages_node=1 hugepages=4

It will allocate 4 hugepags in node1 at boot.

If were going to do this, shouldn't we permit more than one node?

      hugepages_nodes=1,2,5

I'd think we'd be better off expanding the definition of hugepages.
eg:

hugepagesz=1G hugepages=1:4,3:8,5:2

would say to allocate 4 pages from node 1, 8 pages from node 3 and 2
pages from node 5.