From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3BA0C433EF for ; Wed, 15 Sep 2021 14:59:47 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 6815D61212 for ; Wed, 15 Sep 2021 14:59:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6815D61212 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2FAF4068F; Wed, 15 Sep 2021 16:59:46 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 473584014F for ; Wed, 15 Sep 2021 16:59:44 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10107"; a="244711650" X-IronPort-AV: E=Sophos;i="5.85,295,1624345200"; d="scan'208";a="244711650" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Sep 2021 07:59:43 -0700 X-IronPort-AV: E=Sophos;i="5.85,295,1624345200"; d="scan'208";a="470956006" Received: from mmcgar2x-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.252.4.169]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 15 Sep 2021 07:59:41 -0700 Date: Wed, 15 Sep 2021 15:59:38 +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> <26751626.JyCatQyOe0@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26751626.JyCatQyOe0@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 04:39:21PM +0200, Thomas Monjalon wrote: > 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? > I mean the positive and negative log messages. I would assess the positive log level independently of what the log level chosen for the negative one, rather than saying they should be at the same level. > > > 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". > Yes, agreed. The one small advantage of always just reporting in kB is that it is the units used by the kernel in reporting the page sizes: $ ls /sys/kernel/mm/hugepages/ hugepages-1048576kB hugepages-2048kB /Bruce