From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <huawei.xie@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
by dpdk.org (Postfix) with ESMTP id BF7795A68
for <dev@dpdk.org>; Wed, 18 Nov 2015 13:08:17 +0100 (CET)
Received: from orsmga003.jf.intel.com ([10.7.209.27])
by orsmga103.jf.intel.com with ESMTP; 18 Nov 2015 04:08:04 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,312,1444719600"; d="scan'208";a="688407487"
Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202])
by orsmga003.jf.intel.com with ESMTP; 18 Nov 2015 04:08:03 -0800
Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by
fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Wed, 18 Nov 2015 04:08:02 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by
fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS)
id 14.3.248.2; Wed, 18 Nov 2015 04:08:02 -0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.83]) by
SHSMSX103.ccr.corp.intel.com ([169.254.4.138]) with mapi id 14.03.0248.002;
Wed, 18 Nov 2015 20:07:55 +0800
From: "Xie, Huawei" <huawei.xie@intel.com>
To: "Wang, Zhihong" <zhihong.wang@intel.com>, "Mcnamara, John"
<john.mcnamara@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
hugepage zero-filling
Thread-Index: AdEh+cDyRRUaxKXlTJiv4jhXXCoSSw==
Date: Wed, 18 Nov 2015 12:07:54 +0000
Message-ID: <C37D651A908B024F974696C65296B57B4B198CF8@SHSMSX101.ccr.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>
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
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal:
Remove unnecessary hugepage zero-filling
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, 18 Nov 2015 12:08:18 -0000
On 11/18/2015 6:45 PM, Wang, Zhihong wrote:=0A=
>> -----Original Message-----=0A=
>> From: Mcnamara, John=0A=
>> Sent: Wednesday, November 18, 2015 6:40 PM=0A=
>> To: Wang, Zhihong <zhihong.wang@intel.com>; dev@dpdk.org=0A=
>> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessa=
ry=0A=
>> hugepage zero-filling=0A=
>>=0A=
>>=0A=
>>=0A=
>>> -----Original Message-----=0A=
>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhihong Wang=0A=
>>> Sent: Wednesday, November 18, 2015 3:27 AM=0A=
>>> To: dev@dpdk.org=0A=
>>> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary=
=0A=
>>> hugepage zero-filling=0A=
>>>=0A=
>>> The kernel fills new allocated (huge) pages with zeros.=0A=
>>> DPDK just has to touch the pages to trigger the allocation.=0A=
I think we shouldn't reply on the assumption that kernel has zeroed the=0A=
memory. Kernel zeroes the memory mostly to avoid information leakage.It=0A=
could also achieve this by setting each bit to 1.=0A=
What we indeed need to check is later DPDK initialization code doesn't=0A=
assume the memory has been zeroed. Otherwise zero only that part of the=0A=
memory. Does this makes sense?=0A=
=0A=
>>> ...=0A=
>>> if (orig) {=0A=
>>> hugepg_tbl[i].orig_va =3D virtaddr;=0A=
>>> - memset(virtaddr, 0, hugepage_sz);=0A=
>>> + memset(virtaddr, 0, 8);=0A=
>>> }=0A=
>> Probably worth adding a one or two line comment here to avoid someone=0A=
>> thinking that it is a bug at some later stage. The text in the commit me=
ssage=0A=
>> above is suitable.=0A=
>>=0A=
> Good suggestion! Will add it :)=0A=
>=0A=
>> John.=0A=
>> --=0A=
>=0A=
=0A=