All of
 help / color / mirror / Atom feed
From: Thomas Monjalon <>
Subject: [dpdk-dev] logs about hugepages detection
Date: Wed, 15 Sep 2021 15:52:35 +0200	[thread overview]
Message-ID: <1768095.o955dqoAmz@thomas> (raw)


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/ -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.

             reply	other threads:[~2021-09-15 13:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 13:52 Thomas Monjalon [this message]
2021-09-15 14:25 ` [dpdk-dev] logs about hugepages detection Bruce Richardson
2021-09-15 14:39   ` Thomas Monjalon
2021-09-15 14:59     ` Bruce Richardson
2021-09-15 16:34       ` Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1768095.o955dqoAmz@thomas \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.