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 AA720A0C41; Wed, 15 Sep 2021 16:39:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 36FD44068F; Wed, 15 Sep 2021 16:39:27 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id DD8034014F for ; Wed, 15 Sep 2021 16:39:25 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CE2DD3200947; Wed, 15 Sep 2021 10:39:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 15 Sep 2021 10:39:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= GhQXO7Arl6mt+4tbqXmF4df45VPVDASP7hZNTyoVFJQ=; b=KOFjXqqkOcAS0fKc eIuqxgzAPsTvanR/ticGL3sKYTEKs3nQFGSbunthdOIFs+/0KWw4UDrohaMuwzyR YZaMrorbm83S51pGwegrVD8AMy4BwyOhhV1CYFMcU9iB+4avqe26kByljXrIOpxB 3t22xWLmBWcp01FPEFC/gaZdwaJKeQ51tlfMhXiFGUK4mSRGSwOhvUQ2MUs4fN+f fYOkI5XIpP0io4McaQPqb602OoPPa38P3Wzopf1CqHqTYi0QL9nh7cQ6Cd4O58Hk AlA7YwmgJx8cl+CluhN4HdYZV87W0nbsXht20ei/9irdNs4l3i8OjsOa/QO3KFm8 3B03RA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GhQXO7Arl6mt+4tbqXmF4df45VPVDASP7hZNTyoVF JQ=; b=rYk2fUY1jGL1Mb8MIqhBPI/j25R4vyx26qzMCbQI5z2fbBXoxjQZCWUU2 GQaqUPB7gL9uo/ZjcEhqnUQ+Jeg03EL3n23UJSMc12HJPK0FAxKfXoK7dvNEMIBT 2mLYShOBvAezkQPqmW3C49k99C6IKgrBHWtaegBVvyL6oDl3JEs2KOE9b/o2RzX4 g37IUZL6IZT0fzGUvXTcQ+HsxCXPHl3sMsw+kEJRn13rMz5zmr9MIK2uQi2tnV6K iOn0S0+CGZUehnWxiJbMvYsV2jdMq1lQBm1QaH4r1o5naHPrhKgBLIBfKuTTZhAJ 1w8DtYGcQD6+LXLj4o89zvy5C3jfw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehuddgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Sep 2021 10:39:22 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: anatoly.burakov@intel.com, david.marchand@redhat.com, dmitry.kozliuk@gmail.com, dev@dpdk.org Date: Wed, 15 Sep 2021 16:39:21 +0200 Message-ID: <26751626.JyCatQyOe0@thomas> In-Reply-To: References: <1768095.o955dqoAmz@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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" 15/09/2021 16:25, Bruce Richardson: > On Wed, Sep 15, 2021 at 03:52:35PM +0200, Thomas Monjalon wrote: > > 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. > > > > Agreed. > > > 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. > > A bit uncertain about this, as I think it need not always be the case. I > think the log messages should be assessed independently. Not sure what you mean. Which level for which message? > > 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 > > > > Yes, things should be consistent, having highest units is nice-to-have. If > everything is consistently reported in KB or MB it's probably fine. Fine but not nice :) I'm looking to improve the user experience, so "1GB" is definitely easier to read than "1048576 kB", not talking about "1073741824". > > 4/ The unavailability of 1G should be reported only once. > > > I'd actually suggest that the unavailability of 1G pages should not be > reported at all if 2MB pages are available. If we imagine a hypothetical > architecture with 15 hugepage sizes, if more than enough memory is > available for DPDK use via one page size, would we really want to know or > care about the fact that 14 page sizes are unavailable? I agree. > > 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.