DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: maxime.leroy@6wind.com
Subject: [dpdk-dev] [PATCH 2/3] memalloc: improve best-effort allocation
Date: Fri, 22 Feb 2019 16:14:02 +0000	[thread overview]
Message-ID: <64201abe22bfa2726cd312b774861b9aba8625c6.1550851998.git.anatoly.burakov@intel.com> (raw)
In-Reply-To: <def930b90366501f8e301a693b08d27967479633.1550851998.git.anatoly.burakov@intel.com>
In-Reply-To: <def930b90366501f8e301a693b08d27967479633.1550851998.git.anatoly.burakov@intel.com>

Previously, when using non-exact allocation, we were requesting
N pages to be allocated, but allowed the memory subsystem to
allocate less than requested. However, we were still expecting
to see N contigous free pages in the memseg list.

This presents a problem because there is no way to try and
allocate as many pages as possible, even if there isn't
enough contiguous free entries in the list.

To address this, use the new "find biggest" fbarray API's when
allocating non-exact number of pages. This way, we will first
check how many entries in the list are actually available, and
then try to allocate up to that number.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
 lib/librte_eal/linuxapp/eal/eal_memalloc.c | 33 ++++++++++++++++++----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index b6fb183db..14c3ea838 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
@@ -874,10 +874,32 @@ alloc_seg_walk(const struct rte_memseg_list *msl, void *arg)
 	need = wa->n_segs;
 
 	/* try finding space in memseg list */
-	cur_idx = rte_fbarray_find_next_n_free(&cur_msl->memseg_arr, 0, need);
-	if (cur_idx < 0)
-		return 0;
-	start_idx = cur_idx;
+	if (wa->exact) {
+		/* if we require exact number of pages in a list, find them */
+		cur_idx = rte_fbarray_find_next_n_free(&cur_msl->memseg_arr, 0,
+				need);
+		if (cur_idx < 0)
+			return 0;
+		start_idx = cur_idx;
+	} else {
+		int cur_len;
+
+		/* we don't require exact number of pages, so we're going to go
+		 * for best-effort allocation. that means finding the biggest
+		 * unused block, and going with that.
+		 */
+		cur_idx = rte_fbarray_find_biggest_free(&cur_msl->memseg_arr,
+				0);
+		if (cur_idx < 0)
+			return 0;
+		start_idx = cur_idx;
+		/* adjust the size to possibly be smaller than original
+		 * request, but do not allow it to be bigger.
+		 */
+		cur_len = rte_fbarray_find_contig_free(&cur_msl->memseg_arr,
+				cur_idx);
+		need = RTE_MIN(need, (unsigned int)cur_len);
+	}
 
 	/* do not allow any page allocations during the time we're allocating,
 	 * because file creation and locking operations are not atomic,
@@ -954,7 +976,8 @@ alloc_seg_walk(const struct rte_memseg_list *msl, void *arg)
 		cur_msl->version++;
 	if (dir_fd >= 0)
 		close(dir_fd);
-	return 1;
+	/* if we didn't allocate any segments, move on to the next list */
+	return i > 0;
 }
 
 struct free_walk_param {
-- 
2.17.1

  reply	other threads:[~2019-02-22 16:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-22 16:14 [dpdk-dev] [PATCH 1/3] fbarray: add API to find biggest used or free chunks Anatoly Burakov
2019-02-22 16:14 ` Anatoly Burakov [this message]
2019-02-22 16:14 ` [dpdk-dev] [PATCH 3/3] eal: attempt multiple hugepage allocations at init Anatoly Burakov
2019-03-28 22:22   ` Thomas Monjalon
2019-03-28 22: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=64201abe22bfa2726cd312b774861b9aba8625c6.1550851998.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=maxime.leroy@6wind.com \
    /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).