From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <michael.qiu@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 55C0C6A95
 for <dev@dpdk.org>; Thu, 11 Dec 2014 02:45:01 +0100 (CET)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga102.fm.intel.com with ESMTP; 10 Dec 2014 17:44:59 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="427589377"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
 by FMSMGA003.fm.intel.com with ESMTP; 10 Dec 2014 17:34:14 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
 KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS)
 id 14.3.195.1; Thu, 11 Dec 2014 09:44:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
 SHSMSX152.ccr.corp.intel.com ([169.254.6.5]) with mapi id 14.03.0195.001;
 Thu, 11 Dec 2014 09:44:55 +0800
From: "Qiu, Michael" <michael.qiu@intel.com>
To: Jay Rolette <rolette@infiniteio.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>
Thread-Topic: [dpdk-dev] [PATCH] Avoid possible memory cpoy when sort hugepages
Thread-Index: AQHQFMFwbDvf06mMf0CGakJFSjiBzQ==
Date: Thu, 11 Dec 2014 01:44:55 +0000
Message-ID: <533710CFB86FA344BFBF2D6802E60286C9EA4B@SHSMSX101.ccr.corp.intel.com>
References: <1418178341-4193-1-git-send-email-michael.qiu@intel.com>
 <20141210104110.GB10056@bricha3-MOBL3>
 <533710CFB86FA344BFBF2D6802E60286C9E768@SHSMSX101.ccr.corp.intel.com>
 <2601191342CEEE43887BDE71AB977258213BEA97@IRSMSX105.ger.corp.intel.com>
 <CADNuJVr9airTPGpy9r_PD7ys6GRhmabTS22OmCkQr+UbM5WgoQ@mail.gmail.com>
 <2601191342CEEE43887BDE71AB977258213BED0C@IRSMSX105.ger.corp.intel.com>
 <2601191342CEEE43887BDE71AB977258213BED20@IRSMSX105.ger.corp.intel.com>
 <CADNuJVpsNNOymFmmCPGA9hHB84bzT-N90mci6j5YZqVKtCfi3Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <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 <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: Thu, 11 Dec 2014 01:45:01 -0000

On 12/11/2014 5:37 AM, Jay Rolette wrote:=0A=
> On Wed, Dec 10, 2014 at 12:39 PM, Ananyev, Konstantin <=0A=
> konstantin.ananyev@intel.com> wrote:=0A=
>=0A=
>>> I just got through replacing that entire function in my repo with a cal=
l=0A=
>> to qsort() from the standard library last night myself. Faster=0A=
>>> (although probably not material to most deployments) and less code.=0A=
>> If you feel like it is worth it, why not to submit a patch? :)=0A=
>=0A=
> On Haswell and IvyBridge Xeons, with 128 1G huge pages, it doesn't make a=
=0A=
> user-noticeable difference in the time required for=0A=
> rte_eal_hugepage_init(). The reason I went ahead and checked it in my rep=
o=0A=
> is because:=0A=
>=0A=
> a) it eats at my soul to see an O(n^2) case for something where qsort() i=
s=0A=
> trivial to use=0A=
> b) we will increase that up to ~232 1G huge pages soon. Likely doesn't=0A=
> matter at that point either, but since it was already written...=0A=
>=0A=
> What *does* chew up a lot of time in init is where the huge pages are bei=
ng=0A=
> explicitly zeroed in map_all_hugepages().=0A=
>=0A=
> Removing that memset() makes find_numasocket() blow up, but I was able to=
=0A=
> do a quick test where I only memset 1 byte on each page. That cut init ti=
me=0A=
> by 30% (~20 seconds in my test).  Significant, but since I'm not entirely=
=0A=
> sure it is safe, I'm not making that change right now.=0A=
>=0A=
> On Linux, shared memory that isn't file-backed is automatically zeroed=0A=
> before the app gets it. However, I haven't had a chance to chase down=0A=
> whether that applies to huge pages or not, much less how hugetlbfs factor=
s=0A=
> into the equation.=0A=
>=0A=
> Back to the question about the patch, if you guys are interested in it,=
=0A=
> I'll have to figure out your patch submission process. Shouldn't be a hug=
e=0A=
> deal other than the fact that we are on DPDK 1.6 (r2).=0A=
=0A=
Go ahead and post it :)=0A=
=0A=
Thanks,=0A=
Michael=0A=
> Cheers,=0A=
> Jay=0A=
>=0A=
=0A=