From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2205645501; Wed, 26 Jun 2024 16:51:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9A62C4026C; Wed, 26 Jun 2024 16:51:54 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id DE93C40151 for ; Wed, 26 Jun 2024 16:51:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1719413512; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=jCGjg+x5yM14mLsTZzg9SmJ3cAUk8t57OACSLYnDmDY=; b=UiCzT76uBOThZkbWvTS30mBfQzP3SlMyY5/H2GLIKVaVpOHUbvUQGIgE3u2BC6EciTYjvz BgPkvMu0WYdeZsokwNr0XcrLto2uegMCwbj2i7h20iQsi43FTI+UMW0DA3NOfkJ3Ql0QQF oeznzJ67MwfrunpxUuLPBioQqAWwdu8= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-328-oaYjnOheMMC9-22MsViQ_Q-1; Wed, 26 Jun 2024 10:51:49 -0400 X-MC-Unique: oaYjnOheMMC9-22MsViQ_Q-1 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D6CDD1956060; Wed, 26 Jun 2024 14:51:48 +0000 (UTC) Received: from dmarchan.redhat.com (unknown [10.45.225.3]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 007CE19560B2; Wed, 26 Jun 2024 14:51:46 +0000 (UTC) From: David Marchand To: dev@dpdk.org Cc: Ales Musil , stable@dpdk.org, Anatoly Burakov Subject: [PATCH] eal/linux: lower log level on allocation attempt failure Date: Wed, 26 Jun 2024 16:51:42 +0200 Message-ID: <20240626145142.1697935-1-david.marchand@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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") Cc: stable@dpdk.org Signed-off-by: David Marchand --- 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 0cc3295994..e354efc95d 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) { - EAL_LOG(ERR, "%s(): couldn't find suitable memseg_list", + EAL_LOG(DEBUG, "%s(): couldn't find suitable memseg_list", __func__); ret = -1; } else if (ret > 0) { -- 2.45.2