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 A9687A0C41; Wed, 15 Sep 2021 16:26:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 918914068F; Wed, 15 Sep 2021 16:26:04 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 36C084014F for ; Wed, 15 Sep 2021 16:26:03 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10107"; a="220457836" X-IronPort-AV: E=Sophos;i="5.85,295,1624345200"; d="scan'208";a="220457836" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2021 07:26:02 -0700 X-IronPort-AV: E=Sophos;i="5.85,295,1624345200"; d="scan'208";a="553316245" Received: from mmcgar2x-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.4.169]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Sep 2021 07:26:00 -0700 Date: Wed, 15 Sep 2021 15:25:57 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: anatoly.burakov@intel.com, david.marchand@redhat.com, dmitry.kozliuk@gmail.com, dev@dpdk.org Message-ID: References: <1768095.o955dqoAmz@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1768095.o955dqoAmz@thomas> 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" 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. > 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. > 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? > 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. > Regards, /Bruce