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 5C071A0C41; Wed, 15 Sep 2021 15:52:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B6514068F; Wed, 15 Sep 2021 15:52:44 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id F22234003C for ; Wed, 15 Sep 2021 15:52:42 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 388143200952; Wed, 15 Sep 2021 09:52:39 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 15 Sep 2021 09:52:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:content-type; s=fm2; bh=X+m7PS8IAq254 u+0UCECIquYd7PtFn9El2H8lSSWIAk=; b=EdtAEThCgoPPckXUDFKkw5t6eq2Ne XGo80MMEtOb+LC2NcVTVEKX3f/ZswPb8LYQUvsG4JzL1Rmnp9tUJw758YBlgszCW D1iST0qa9XEMnJNfpTi9iTP5m3qVRjcfVf2AsRsV/7OAfXCvQIVyMXkKX+roud2m OwXjtA7CTpo5HbDrI9fcJUGWL+mAiLADufj8j7HoCYfOx1QoKjKkD7JD68EGOQjr jNb06tlWKNODLX5wrkvxXq7fK8igEjKfTBNOILeHiX/7r+52kYRDv1Fn/Xea2mek yEGH3lpMDvNgxzlPhi1KFYS42tOXWS1bxxs0rRL+hn64a2q9Os8F9n/qA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=X+m7PS 8IAq254u+0UCECIquYd7PtFn9El2H8lSSWIAk=; b=IJBwCTpf2UQ/reUbULSaZ1 /QVjqoDscxJgXiYGvc165PZYbbI8vLLJKrgeMEuWXiHuKlzppew3bm4VKcPiVhHd nQcJOR39itEOpruojU1e8YbqsMu2hzU2z+238lMYjIWi3Ib1tbV8L+CaoEFO0GhW K5JG1DkEDt37/SB1eLb+5r+JaFyNVIJ7lS7fqOO0fwsXFiJcHdf4L4bRabaRjOVX wLrE7qPfDtScCzCEfcL/4VALCzXxqkZ/UsDpm5fTYiaBHCIFozzWXT8DEXiz4fu5 zNXlDGxAbMtoxmR4hqOhM90DILFMpeOSQyb0zFm1AzVieQZt5r/2TQzzBg+4IpJg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehuddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkggfgtgesthfuredttd dtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhho nhhjrghlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpeeujeduhedtjeegueejhfetje egtdfgheeuueeivdeuhfeijefhffdufeegjefhkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvg ht X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Sep 2021 09:52:37 -0400 (EDT) From: Thomas Monjalon To: anatoly.burakov@intel.com Cc: david.marchand@redhat.com, bruce.richardson@intel.com, dmitry.kozliuk@gmail.com, dev@dpdk.org Date: Wed, 15 Sep 2021 15:52:35 +0200 Message-ID: <1768095.o955dqoAmz@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: [dpdk-dev] logs about hugepages detection 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 Sender: "dev" Hi, I would like to discuss some issues in logging of hugepage lookup. The issues to be discussed will be enumerated and numbered below. I will take an example of an x86 machine with 2M and 1G pages. I reserve only 2M pages: usertools/dpdk-hugepages.py -p 2M -r 80M If I start a DPDK application with --log-level info the only message I read makes me think something is wrong: EAL: No available 1048576 kB hugepages reported 1/ Log level is too high. If I start with EAL in debug level, I can see which page size is used: --log-level debug --log-level lib.eal:debug EAL: No available 1048576 kB hugepages reported [...] EAL: Detected memory type: socket_id:0 hugepage_sz:2097152 2/ The positive message should be at the same level as the negative one. 3/ The sizes are sometimes written in bytes, sometimes in kB. It should be always the highest unit, including GB. When using the --in-memory mode, things are worst: EAL: No available 1048576 kB hugepages reported 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: No available 1048576 kB hugepages reported [...] EAL: Detected memory type: socket_id:0 hugepage_sz:1073741824 EAL: Detected memory type: socket_id:0 hugepage_sz:2097152 4/ The unavailability of 1G should be reported only once. 5/ If non-reserved pages can be used without reservation, it should be better documented. Please correct me if I'm wrong, and give your opinion. I could work on some patches if needed.