From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 7357A8DAC for ; Mon, 23 Nov 2015 04:46:35 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 22 Nov 2015 19:46:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,335,1444719600"; d="scan'208";a="844995824" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga001.fm.intel.com with ESMTP; 22 Nov 2015 19:46:35 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 22 Nov 2015 19:46:34 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 22 Nov 2015 19:46:33 -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; Mon, 23 Nov 2015 11:46:32 +0800 From: "Xie, Huawei" To: "Gonzalez Monroy, Sergio" , "Wang, Zhihong" , "Mcnamara, John" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Thread-Index: AQHRJaGKxL2Z5sKfnk+JPinAT7c0ug== Date: Mon, 23 Nov 2015 03:46:31 +0000 Message-ID: References: <1447817231-10510-1-git-send-email-zhihong.wang@intel.com> <1447817231-10510-3-git-send-email-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE094183467C@SHSMSX152.ccr.corp.intel.com> <564D930C.7060108@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 03:46:36 -0000 On 11/19/2015 5:15 PM, Gonzalez Monroy, Sergio wrote:=0A= > On 18/11/2015 12:07, Xie, Huawei wrote:=0A= >> 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 ; dev@dpdk.org=0A= >>>> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove=0A= >>>> unnecessary=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=0A= >>>>> 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= > Why cannot we rely on the kernel zeroing the memory ?=0A= > If that behavior were to change, then we can zero out the memory=0A= > ourselves.=0A= It is undocumented kernel behavior. My opinion is if not a big burden,=0A= zero out the needed memory ourselves, otherwise resort to this kernel=0A= behavior.=0A= =0A= >=0A= > Bruce pointed out to me that the semantics have changed a bit since we=0A= > introduced=0A= > rte_memzone_free.=0A= > Before that, all memzone reserve were zero out by default.=0A= > Is there code relying on that? I'm not sure, but it still is good=0A= > practice to do it.=0A= >=0A= > I submitted an RFC regarding this:=0A= > http://dpdk.org/ml/archives/dev/2015-November/028416.html=0A= >=0A= > The idea would be to keep the available memory we are managing zeroed=0A= > at all times.=0A= >=0A= > Sergio=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=0A= >>>> commit message=0A= >>>> above is suitable.=0A= >>>>=0A= >>> Good suggestion! Will add it :)=0A= >>>=0A= >>>> John.=0A= >>>> -- =0A= >=0A= >=0A= =0A=