From patchwork Wed Dec 10 02:25:41 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Qiu X-Patchwork-Id: 1910 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 9328F7E79; Wed, 10 Dec 2014 03:26:15 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 56A7B6A8B for ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 --- 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],