From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dayuqiu@shecgisg003.sh.intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by dpdk.org (Postfix) with ESMTP id 56A7B6A8B
for <dev@dpdk.org>; Wed, 10 Dec 2014 03:26:13 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by orsmga102.jf.intel.com with ESMTP; 09 Dec 2014 18:24:50 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,549,1413270000"; d="scan'208";a="651311486"
Received: from shvmail01.sh.intel.com ([10.239.29.42])
by orsmga002.jf.intel.com with ESMTP; 09 Dec 2014 18:25:47 -0800
Received: from shecgisg003.sh.intel.com (shecgisg003.sh.intel.com
[10.239.29.90])
by shvmail01.sh.intel.com with ESMTP id sBA2PjAC010271;
Wed, 10 Dec 2014 10:25:45 +0800
Received: from shecgisg003.sh.intel.com (localhost [127.0.0.1])
by shecgisg003.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id
sBA2PgCG004229; Wed, 10 Dec 2014 10:25:44 +0800
Received: (from dayuqiu@localhost)
by shecgisg003.sh.intel.com (8.13.6/8.13.6/Submit) id sBA2Pgjv004225;
Wed, 10 Dec 2014 10:25:42 +0800
From: Michael Qiu <michael.qiu@intel.com>
To: dev@dpdk.org
Date: Wed, 10 Dec 2014 10:25:41 +0800
Message-Id: <1418178341-4193-1-git-send-email-michael.qiu@intel.com>
X-Mailer: git-send-email 1.7.4.1
Subject: [dpdk-dev] [PATCH] Avoid possible memory cpoy when sort hugepages
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Dec 2014 02:26:13 -0000
When the first address is the compared address in the loop,
it will also do memory copy, which is meaningless,
worse more, when hugepg_tbl is mostly in order. This should
be a big deal in large hugepage memory systerm(like hunderd
or thousand GB).
Meanwhile smallest_idx never be a value of -1,so remove this check.
This patch also includes some coding style fix.
Signed-off-by: Michael Qiu <michael.qiu@intel.com>
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index e6cb919..700aba2 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -678,14 +678,13 @@ error:
static int
sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
{
- unsigned i, j;
- int compare_idx;
+ unsigned i, j, compare_idx;
uint64_t compare_addr;
struct hugepage_file tmp;
for (i = 0; i < hpi->num_pages[0]; i++) {
compare_addr = 0;
- compare_idx = -1;
+ compare_idx = i;
/*
* browse all entries starting at 'i', and find the
@@ -704,11 +703,9 @@ sort_by_physaddr(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
}
}
- /* should not happen */
- if (compare_idx == -1) {
- RTE_LOG(ERR, EAL, "%s(): error in physaddr sorting\n", __func__);
- return -1;
- }
+ /* avoid memory copy when the first entry is the compared */
+ if (compare_idx == i)
+ continue;
/* swap the 2 entries in the table */
memcpy(&tmp, &hugepg_tbl[compare_idx],
--
1.9.3