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 2E7588E81 for ; Wed, 25 Nov 2015 02:59:16 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 24 Nov 2015 17:59:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,341,1444719600"; d="scan'208";a="846499906" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 24 Nov 2015 17:59:15 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 24 Nov 2015 17:59:14 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 24 Nov 2015 17:59:14 -0800 Received: from shsmsx152.ccr.corp.intel.com ([169.254.6.193]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.138]) with mapi id 14.03.0248.002; Wed, 25 Nov 2015 09:59:12 +0800 From: "Wang, Zhihong" To: Thomas Monjalon , Stephen Hemminger Thread-Topic: [dpdk-dev] [PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Thread-Index: AQHRJZTwuyrnl9lGzEGXNdbuP7BK0Z6oW94AgALMyACAABlPgIAABaYAgAC1H8A= Date: Wed, 25 Nov 2015 01:59:12 +0000 Message-ID: <8F6C2BD409508844A0EFC19955BE0941835ADD@SHSMSX152.ccr.corp.intel.com> References: <1448219615-63746-1-git-send-email-zhihong.wang@intel.com> <1640963.TLMeDD9tfp@xps13> <20151124144403.79811c0a@xeon-e3> <3179262.cyHqZdDHPg@xps13> In-Reply-To: <3179262.cyHqZdDHPg@xps13> 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" Subject: Re: [dpdk-dev] [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: Wed, 25 Nov 2015 01:59:16 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, November 25, 2015 7:04 AM > To: Stephen Hemminger > Cc: Wang, Zhihong ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/2] lib/librte_eal: Remove unnecessary > hugepage zero-filling >=20 > 2015-11-24 14:44, Stephen Hemminger: > > On Tue, 24 Nov 2015 22:13:28 +0100 > > Thomas Monjalon wrote: > > > > > 2015-11-22 18:28, Stephen Hemminger: > > > > On Sun, 22 Nov 2015 14:13:35 -0500 Zhihong Wang > > > > wrote: > > > > > > > > > The kernel fills new allocated (huge) pages with zeros. > > > > > DPDK just has to populate page tables to trigger the allocation. > > > > > > > > > > Signed-off-by: Zhihong Wang > > > > > > > > Nice, especially on slow machines or with large memory. > > > > > > > > Acked-by: Stephen Hemminger > > > > > > Yes very nice. > > > I think it's too late to integrate this change which can have some > > > unpredictable side effects. > > > Do you agree to wait for 2.3? > > > > What side effects? Either it is zero or it is not. > > Only some broken architecture would have an issue. >=20 > I mean it changes the memory allocator behaviour. It's not something we w= ant to > discover a new bug just before the release. > This kind of important change must be integrated at the beginning of the = release > cycle. > I'm asking for opinions because it would be really nice to have. Literally this patch doesn't change anything, it just keeps DPDK from zero-= filling pages again which have just been zero-filled. It would be nice to have this patch in DPDK 2.2 since it can reduce the sta= rtup time nearly by half for hugepage cases. But I understand longer merge/test window make it safer for a release. It makes sense either way.