From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rolette@infiniteio.com>
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com
 [209.85.160.177]) by dpdk.org (Postfix) with ESMTP id D11433F9
 for <dev@dpdk.org>; Wed, 10 Dec 2014 22:36:38 +0100 (CET)
Received: by mail-yk0-f177.google.com with SMTP id 9so1620352ykp.8
 for <dev@dpdk.org>; Wed, 10 Dec 2014 13:36:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:date
 :message-id:subject:from:to:cc:content-type;
 bh=k121qXLwmO5caApZS66JBAJdId2wg54MoqlGA3dRj58=;
 b=UvNomJXunOfp2r2xS5JDh8eOCg5uKVZBOcfR/SQYUG18/7gTRgQEvuexk5/GiFpKFN
 4Uvu8HVreET+RIGsIr56xbh1DXag5amBbyx7SZbmBU+0OF1Ts8KA9iv36hpSed54EKbb
 0R2lM5aEepMBmZu9jfQFhuqDWwW7xwunxuWkP1aclgRnhJXPpG2XLQ05uYyT15pnb5Ia
 w9bycu256WiBYZdS788DGTknV7obBH8usIPeTXGn4v1VjNzMYs3DQGVZ9/4lhVpEEMhD
 YMrly0QKVG6V6OlaOajcxoAHIDy0eQb9ge0idkfrygGcyqYT0I5++8r2uBkCE6QkjA44
 eYNA==
X-Gm-Message-State: ALoCoQn5MDg78vh7jq52LysUbOt3agOcm1LGz1lGAl7nQhDu7U0tVY9yboAyJj0bZS1pdoyal7gZ
MIME-Version: 1.0
X-Received: by 10.236.228.101 with SMTP id e95mr5215637yhq.56.1418247398042;
 Wed, 10 Dec 2014 13:36:38 -0800 (PST)
Received: by 10.170.54.78 with HTTP; Wed, 10 Dec 2014 13:36:37 -0800 (PST)
In-Reply-To: <2601191342CEEE43887BDE71AB977258213BED20@IRSMSX105.ger.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>
Date: Wed, 10 Dec 2014 15:36:37 -0600
Message-ID: <CADNuJVpsNNOymFmmCPGA9hHB84bzT-N90mci6j5YZqVKtCfi3Q@mail.gmail.com>
From: Jay Rolette <rolette@infiniteio.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
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: Wed, 10 Dec 2014 21:36:39 -0000

On Wed, Dec 10, 2014 at 12:39 PM, Ananyev, Konstantin <
konstantin.ananyev@intel.com> wrote:

> > I just got through replacing that entire function in my repo with a call
> to qsort() from the standard library last night myself. Faster
> > (although probably not material to most deployments) and less code.
>
> If you feel like it is worth it, why not to submit a patch? :)


On Haswell and IvyBridge Xeons, with 128 1G huge pages, it doesn't make a
user-noticeable difference in the time required for
rte_eal_hugepage_init(). The reason I went ahead and checked it in my repo
is because:

a) it eats at my soul to see an O(n^2) case for something where qsort() is
trivial to use
b) we will increase that up to ~232 1G huge pages soon. Likely doesn't
matter at that point either, but since it was already written...

What *does* chew up a lot of time in init is where the huge pages are being
explicitly zeroed in map_all_hugepages().

Removing that memset() makes find_numasocket() blow up, but I was able to
do a quick test where I only memset 1 byte on each page. That cut init time
by 30% (~20 seconds in my test).  Significant, but since I'm not entirely
sure it is safe, I'm not making that change right now.

On Linux, shared memory that isn't file-backed is automatically zeroed
before the app gets it. However, I haven't had a chance to chase down
whether that applies to huge pages or not, much less how hugetlbfs factors
into the equation.

Back to the question about the patch, if you guys are interested in it,
I'll have to figure out your patch submission process. Shouldn't be a huge
deal other than the fact that we are on DPDK 1.6 (r2).

Cheers,
Jay