From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C12BF7E23 for ; Wed, 10 Dec 2014 11:41:14 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 02:41:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,551,1413270000"; d="scan'208";a="635479097" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.31]) by fmsmga001.fm.intel.com with SMTP; 10 Dec 2014 02:41:11 -0800 Received: by (sSMTP sendmail emulation); Wed, 10 Dec 2014 10:41:10 +0025 Date: Wed, 10 Dec 2014 10:41:10 +0000 From: Bruce Richardson To: Michael Qiu Message-ID: <20141210104110.GB10056@bricha3-MOBL3> References: <1418178341-4193-1-git-send-email-michael.qiu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1418178341-4193-1-git-send-email-michael.qiu@intel.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [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: , X-List-Received-Date: Wed, 10 Dec 2014 10:41:15 -0000 On Wed, Dec 10, 2014 at 10:25:41AM +0800, Michael Qiu wrote: > 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). I actually doubt the time taken by this sorting is a significant part of the initialization time taken, even for hundreds of GBs of memory. Do you have any measurements to confirm this? [However, that's not to say that we can't merge in this patch] > > 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], > -- > 1.9.3 >