aboutsummaryrefslogtreecommitdiffstats
path: root/src/vpp-api/java/jvpp-acl/io
diff options
context:
space:
mode:
authorJay Wang <jay.wang2@arm.com>2024-04-19 12:16:41 +0000
committerDamjan Marion <dmarion@0xa5.net>2024-07-09 15:35:52 +0000
commitc44fa9355bb8a5f0315c49ed56bc44799e1fd84f (patch)
treeacd93d291d2ff0067378a320ecec7b5aa3439733 /src/vpp-api/java/jvpp-acl/io
parent3fe610a2aae76263b44864b8239c22951c67e752 (diff)
vppinfra: fix huge page alloc error on 5.19+ kernel
Running VPP on a NUMA system with 5.19+ kernel outputs the following error messages. 'show physmem' command confirms that VPP falls back to using normal 4K pages instead of the preallocated 1G huge pages. The root cause is that VPP uses move_pages()[1] to get the huge page node information. However, this misbehaves on the 5.19+ kernel due to changes introduced in its implementation[2]. Our proposed fix is retry obtaining NUMA node info with get_mempolicy()[3] only if we see -ENOENT returned in status from move_pages() and huge pages are used. Additionally, we use mincore()[4] to check if pages are allocated and in memory to avoid the possibility of get_mempolicy() falsely allocating a new page. buffer [warn ]: numa[1] falling back to non-hugepage backed buffer pool () vpp# show physmem used-pages 2 reserved-pages 16 default-page-size 1G lookup-page-size 4K arena 'buffers-numa-0' pages 1 subpage-size 1G numa-node 0 shared fd 5 arena 'buffers-numa-1' pages 1 subpage-size 4K numa-node 1 shared fd 6 [1] https://man7.org/linux/man-pages/man2/move_pages.2.html [2] https://lore.kernel.org/linux-mm/91da2c3b-96f1-bb03-8fff-4c38f31cb9be@huawei.com/ [3] https://man7.org/linux/man-pages/man2/get_mempolicy.2.html [4] https://man7.org/linux/man-pages/man2/mincore.2.html Type: fix Signed-off-by: Jay Wang <jay.wang2@arm.com> Change-Id: Ia423745423bb080404292333ef95455a4950ce0a
Diffstat (limited to 'src/vpp-api/java/jvpp-acl/io')
0 files changed, 0 insertions, 0 deletions