DPDK patches and discussions
 help / color / mirror / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: anatoly.burakov@intel.com, thomas@monjalon.net
Cc: dev@dpdk.org, stable@dpdk.org, alejandro.lucero@netronome.com
Subject: [dpdk-dev] [PATCH v2] mem: limit use of address hint
Date: Sun, 31 Mar 2019 11:43:48 +0300	[thread overview]
Message-ID: <20190331084348.4740-1-shahafs@mellanox.com> (raw)
Message-ID: <20190331084348.pjh48cAhzvop-qH_oCq5UiqHsffSjVoGdSID91v6pUU@z> (raw)
In-Reply-To: <20190321202156.117496-1-shahafs@mellanox.com>

patch[1] added an address hint as starting address for 64 bit systems in
case an explicit base virtual address was not set by the user.

The justification for such hint was to help devices that work in VA
mode and has a address range limitation to work smoothly with the eal
memory subsystem.

While the base address value selected may work fine for the eal
initialization, it easily breaks when trying to register external memory
using rte_extmem_register API.

Trying to register anonymous memory on RH x86_64 machine took several
minutes, during them the function eal_get_virtual_area repeatedly
scanned for a good VA candidate.

The attempt to guess which VA address will be free for mapping will
always result in not portable, error prone code:
* different application may use different libraries along w/ DPDK. One
  can never guess which library was called first and how much virtual
  memory it consumed.
* external memory can be registered at any time in the application run
  time.

In order not to break the existing secondary process design, this patch
only limits the max number of tries that will be done with the
address hint.
When the number of tries exceeds the threshold the code
will use the suggested address from kernel.

Fixes: 1df21702873d ("mem: use address hint for mapping hugepages")
Cc: stable@dpdk.org
Cc: alejandro.lucero@netronome.com

[1] commit 1df21702873d ("mem: use address hint for mapping hugepages")

Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
---

On v2:
 * instead of a complete remove of the hint limit the number of tries we allow.
---
 lib/librte_eal/common/eal_common_memory.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index c9da69b164..5ae8d0124d 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -56,6 +56,7 @@ static uint64_t system_page_sz;
 static uint64_t baseaddr = 0x100000000;
 #endif
 
+#define MAX_MMAP_WITH_DEFINED_ADDR_TRIES 5
 void *
 eal_get_virtual_area(void *requested_addr, size_t *size,
 		size_t page_sz, int flags, int mmap_flags)
@@ -63,6 +64,7 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
 	bool addr_is_hint, allow_shrink, unmap, no_align;
 	uint64_t map_sz;
 	void *mapped_addr, *aligned_addr;
+	uint8_t try = 0;
 
 	if (system_page_sz == 0)
 		system_page_sz = sysconf(_SC_PAGESIZE);
@@ -118,11 +120,14 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
 
 		if (mapped_addr != MAP_FAILED && addr_is_hint &&
 		    mapped_addr != requested_addr) {
-			/* hint was not used. Try with another offset */
-			munmap(mapped_addr, map_sz);
-			mapped_addr = MAP_FAILED;
+			try++;
 			next_baseaddr = RTE_PTR_ADD(next_baseaddr, page_sz);
-			requested_addr = next_baseaddr;
+			if (try <= MAX_MMAP_WITH_DEFINED_ADDR_TRIES) {
+				/* hint was not used. Try with another offset */
+				munmap(mapped_addr, map_sz);
+				mapped_addr = MAP_FAILED;
+				requested_addr = next_baseaddr;
+			}
 		}
 	} while ((allow_shrink || addr_is_hint) &&
 		 mapped_addr == MAP_FAILED && *size > 0);
-- 
2.12.0


  parent reply	other threads:[~2019-03-31  8:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-21 20:21 [dpdk-dev] [PATCH] mem: don't use address hint for mapping unless requested Shahaf Shuler
2019-03-21 20:21 ` Shahaf Shuler
2019-03-27  5:36 ` Shahaf Shuler
2019-03-27  5:36   ` Shahaf Shuler
2019-03-27 11:49 ` Burakov, Anatoly
2019-03-27 11:49   ` Burakov, Anatoly
2019-03-28  8:45   ` Shahaf Shuler
2019-03-28  8:45     ` Shahaf Shuler
2019-03-28 10:26     ` Burakov, Anatoly
2019-03-28 10:26       ` Burakov, Anatoly
2019-03-31  8:43 ` Shahaf Shuler [this message]
2019-03-31  8:43   ` [dpdk-dev] [PATCH v2] mem: limit use of address hint Shahaf Shuler
2019-04-02 16:13   ` Burakov, Anatoly
2019-04-02 16:13     ` Burakov, Anatoly
2019-04-02 17:23     ` Alejandro Lucero
2019-04-02 17:23       ` Alejandro Lucero
2019-04-03 17:22       ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2019-04-03 17:22         ` Thomas Monjalon

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20190331084348.4740-1-shahafs@mellanox.com \
    --to=shahafs@mellanox.com \
    --cc=alejandro.lucero@netronome.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).