patch 'eal/linux: lower log level on allocation attempt failure' has been queued to stable release 23.11.2

[Xueming Li]

Hi,

FYI, your patch has been queued to stable release 23.11.2

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 08/14/24. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://git.dpdk.org/dpdk-stable/log/?h=23.11-staging

This queued commit can be viewed at:
https://git.dpdk.org/dpdk-stable/commit/?h=23.11-staging&id=f563086258ad779c923da91ddfe8a918ac8ca3a5

Thanks.

Xueming Li <xuemingl at nvidia.com>

---
>From f563086258ad779c923da91ddfe8a918ac8ca3a5 Mon Sep 17 00:00:00 2001
From: David Marchand <david.marchand at redhat.com>
Date: Wed, 26 Jun 2024 16:51:42 +0200
Subject: [PATCH] eal/linux: lower log level on allocation attempt failure
Cc: Xueming Li <xuemingl at nvidia.com>

[ upstream commit 8f4611d893b4eeffb942fffdadc4cde394e4c309 ]

On a ARM system with only 2MB hugepages configured, EAL emits an error
log with allocations larger than 512MB.

Example with testpmd:
$ dpdk-testpmd --in-memory --no-pci --log-level=*:debug -- -i
...
EAL: In-memory mode enabled, hugepages of size 33554432 bytes will be
	allocated anonymously
EAL: No free 32768 kB hugepages reported on node 0
EAL: In-memory mode enabled, hugepages of size 65536 bytes will be
	allocated anonymously
EAL: No free 64 kB hugepages reported on node 0
EAL: In-memory mode enabled, hugepages of size 1073741824 bytes will be
	allocated anonymously
EAL: No free 1048576 kB hugepages reported on node 0
...
EAL: Detected memory type: socket_id:0 hugepage_sz:1073741824
EAL: Detected memory type: socket_id:0 hugepage_sz:33554432
EAL: Detected memory type: socket_id:0 hugepage_sz:2097152
EAL: Detected memory type: socket_id:0 hugepage_sz:65536
EAL: Creating 2 segment lists: n_segs:32 socket_id:0
	hugepage_sz:1073741824
...
EAL: Creating 2 segment lists: n_segs:1024 socket_id:0
	hugepage_sz:33554432
...
EAL: Creating 4 segment lists: n_segs:8192 socket_id:0
	hugepage_sz:2097152
...
EAL: Creating 4 segment lists: n_segs:8192 socket_id:0
	hugepage_sz:65536
...
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: alloc_seg(): mmap() failed: Cannot allocate memory
EAL: Ask a virtual area of 0x40000000 bytes
EAL: Virtual area found at 0x140000000 (size = 0x40000000)
EAL: attempted to allocate 2 segments, but only 0 were allocated
EAL: Restoring previous memory policy: 4
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: eal_memalloc_alloc_seg_bulk(): couldn't find suitable memseg_list
EAL: Restoring previous memory policy: 4
EAL: Trying to obtain current memory policy.
EAL: Setting policy MPOL_PREFERRED for socket 0
EAL: Restoring previous memory policy: 4
EAL: request: mp_malloc_sync
EAL: No shared files mode enabled, IPC is disabled
EAL: Heap on socket 0 was expanded by 1064MB
...

The reason is that the memzone allocation (~1GB large) would require
17017 (32kB) segments. However, as displayed in the early logs, a 32kB
memory segment list can only host 8192 segments (controlled by the build
option RTE_MAX_MEMSEG_PER_LIST).

This log message is misleading as there is no issue in the end: the
allocation succeeded with 2MB hugepages.

Fixes: 582bed1e1d1d ("mem: support mapping hugepages at runtime")

Signed-off-by: David Marchand <david.marchand at redhat.com>
Acked-by: Stephen Hemminger <stephen at networkplumber.org>
---
 lib/eal/linux/eal_memalloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c
index 9853ec78a2..b9fc83fe6a 100644
--- a/lib/eal/linux/eal_memalloc.c
+++ b/lib/eal/linux/eal_memalloc.c
@@ -1061,7 +1061,7 @@ eal_memalloc_alloc_seg_bulk(struct rte_memseg **ms, int n_segs, size_t page_sz,
 	/* memalloc is locked, so it's safe to use thread-unsafe version */
 	ret = rte_memseg_list_walk_thread_unsafe(alloc_seg_walk, &wa);
 	if (ret == 0) {
-		RTE_LOG(ERR, EAL, "%s(): couldn't find suitable memseg_list\n",
+		RTE_LOG(DEBUG, EAL, "%s(): couldn't find suitable memseg_list\n",
 			__func__);
 		ret = -1;
 	} else if (ret > 0) {
-- 
2.34.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2024-08-12 20:44:03.785595698 +0800
+++ 0039-eal-linux-lower-log-level-on-allocation-attempt-fail.patch	2024-08-12 20:44:02.015069279 +0800
@@ -1 +1 @@
-From 8f4611d893b4eeffb942fffdadc4cde394e4c309 Mon Sep 17 00:00:00 2001
+From f563086258ad779c923da91ddfe8a918ac8ca3a5 Mon Sep 17 00:00:00 2001
@@ -4,0 +5,3 @@
+Cc: Xueming Li <xuemingl at nvidia.com>
+
+[ upstream commit 8f4611d893b4eeffb942fffdadc4cde394e4c309 ]
@@ -66 +68,0 @@
-Cc: stable at dpdk.org
@@ -75 +77 @@
-index 0cc3295994..e354efc95d 100644
+index 9853ec78a2..b9fc83fe6a 100644
@@ -82,2 +84,2 @@
--		EAL_LOG(ERR, "%s(): couldn't find suitable memseg_list",
-+		EAL_LOG(DEBUG, "%s(): couldn't find suitable memseg_list",
+-		RTE_LOG(ERR, EAL, "%s(): couldn't find suitable memseg_list\n",
++		RTE_LOG(DEBUG, EAL, "%s(): couldn't find suitable memseg_list\n",