From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [RFC PATCH 2/2] lib/librte_eal: Remove	unnecessary
 hugepage zero-filling
Date: Wed, 18 Nov 2015 16:13:32 +0000
Message-ID: <59AF69C657FD0841A61C55336867B5B035985B24@IRSMSX103.ger.corp.intel.com>
References: <1447817231-10510-1-git-send-email-zhihong.wang@intel.com>
 <1447817231-10510-3-git-send-email-zhihong.wang@intel.com>
 <B27915DBBA3421428155699D51E4CFE2023BE52A@IRSMSX103.ger.corp.intel.com>
 <8F6C2BD409508844A0EFC19955BE094183467C@SHSMSX152.ccr.corp.intel.com>
 <C37D651A908B024F974696C65296B57B4B198CF8@SHSMSX101.ccr.corp.intel.com>
 <20151118080013.3cad8f5b@samsung9>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: Stephen Hemminger <stephen@networkplumber.org>, "Xie, Huawei"
 <huawei.xie@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id 820573979
 for <dev@dpdk.org>; Wed, 18 Nov 2015 17:19:24 +0100 (CET)
In-Reply-To: <20151118080013.3cad8f5b@samsung9>
Content-Language: en-US
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Wednesday, November 18, 2015 4:00 PM
> To: Xie, Huawei <huawei.xie@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessar=
y
> hugepage zero-filling
>=20
> On Wed, 18 Nov 2015 12:07:54 +0000
> "Xie, Huawei" <huawei.xie@intel.com> wrote:
>=20
> > >>> The kernel fills new allocated (huge) pages with zeros.
> > >>> DPDK just has to touch the pages to trigger the allocation.
> > I think we shouldn't reply on the assumption that kernel has zeroed
> > the memory. Kernel zeroes the memory mostly to avoid information
> > leakage.It could also achieve this by setting each bit to 1.
> > What we indeed need to check is later DPDK initialization code doesn't
> > assume the memory has been zeroed. Otherwise zero only that part of
> > the memory. Does this makes sense?
>=20
> If all new pages are zero, why does DPDK have to pre-touch the pages at
> all?

The pages won't actually be mapped into the processes address space until a=
ccessed.=20

/Bruce