From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <aburakov@ecsmtp.ir.intel.com>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by dpdk.org (Postfix) with ESMTP id 81B317D02
for <dev@dpdk.org>; Thu, 19 Apr 2018 18:35:28 +0200 (CEST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
19 Apr 2018 09:35:27 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.48,469,1517904000"; d="scan'208";a="33189167"
Received: from irvmail001.ir.intel.com ([163.33.26.43])
by fmsmga007.fm.intel.com with ESMTP; 19 Apr 2018 09:35:26 -0700
Received: from sivswdev01.ir.intel.com (sivswdev01.ir.intel.com
[10.237.217.45])
by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id
w3JGZPeQ024535 for <dev@dpdk.org>; Thu, 19 Apr 2018 17:35:25 +0100
Received: from sivswdev01.ir.intel.com (localhost [127.0.0.1])
by sivswdev01.ir.intel.com with ESMTP id w3JGZP6N000309
for <dev@dpdk.org>; Thu, 19 Apr 2018 17:35:25 +0100
Received: (from aburakov@localhost)
by sivswdev01.ir.intel.com with LOCAL id w3JGZPON000305
for dev@dpdk.org; Thu, 19 Apr 2018 17:35:25 +0100
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Date: Thu, 19 Apr 2018 17:35:25 +0100
Message-Id: <be863f870fc02ea6464d15c87fa43e9d274f3240.1524155435.git.anatoly.burakov@intel.com>
X-Mailer: git-send-email 1.7.0.7
Subject: [dpdk-dev] [PATCH] mem: unmap unneeded space
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2018 16:35:28 -0000
When we ask to reserve virtual areas, we usually include
alignment in the mapping size, and that memory ends up
being wasted. Wasting a gigabyte of VA space while trying to
reserve one gigabyte is pretty expensive on 32-bit, so after
we're done mapping, unmap unneeded space.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/common/eal_common_memory.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index 24a9ed5..8dd026a 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -75,8 +75,13 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
do {
map_sz = no_align ? *size : *size + page_sz;
+ if (map_sz > SIZE_MAX) {
+ RTE_LOG(ERR, EAL, "Map size too big\n");
+ rte_errno = E2BIG;
+ return NULL;
+ }
- mapped_addr = mmap(requested_addr, map_sz, PROT_READ,
+ mapped_addr = mmap(requested_addr, (size_t)map_sz, PROT_READ,
mmap_flags, -1, 0);
if (mapped_addr == MAP_FAILED && allow_shrink)
*size -= page_sz;
@@ -113,8 +118,22 @@ eal_get_virtual_area(void *requested_addr, size_t *size,
RTE_LOG(WARNING, EAL, " This may cause issues with mapping memory into secondary processes\n");
}
- if (unmap)
+ if (unmap) {
munmap(mapped_addr, map_sz);
+ } else if (!no_align) {
+ void *unmap_pre, *unmap_post, *map_end;
+ size_t pre_len, post_len;
+
+ /* unmap all of the extra space */
+ unmap_pre = mapped_addr;
+ pre_len = RTE_PTR_DIFF(aligned_addr, mapped_addr);
+ map_end = RTE_PTR_ADD(mapped_addr, (size_t)map_sz);
+ unmap_post = RTE_PTR_ADD(aligned_addr, *size);
+ post_len = RTE_PTR_DIFF(map_end, unmap_post);
+
+ munmap(unmap_pre, pre_len);
+ munmap(unmap_post, post_len);
+ }
RTE_LOG(DEBUG, EAL, "Virtual area found at %p (size = 0x%zx)\n",
aligned_addr, *size);
--
2.7.4