From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 889B1A0613 for ; Tue, 27 Aug 2019 14:48:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 259791C0C9; Tue, 27 Aug 2019 14:48:58 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 5AAA11C035 for ; Tue, 27 Aug 2019 14:48:56 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 05:48:55 -0700 X-IronPort-AV: E=Sophos;i="5.64,437,1559545200"; d="scan'208";a="174538782" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 05:48:54 -0700 Date: Tue, 27 Aug 2019 13:48:51 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: Jim Harris , dev@dpdk.org Message-ID: <20190827124851.GA591@bricha3-MOBL.ger.corp.intel.com> References: <156646334762.14099.13593080473257757748.stgit@jrharri1-skx> <156682708634.28714.543470193614987025.stgit@jrharri1-skx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v5] eal: use memzone to share tsc hz with secondary processes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Aug 27, 2019 at 01:04:18PM +0100, Burakov, Anatoly wrote: > On 26-Aug-19 2:44 PM, Jim Harris wrote: > > Ideally, get_tsc_freq_arch() is able to provide the > > TSC rate using arch-specific means. When that is not > > possible, DPDK reverts to calculating the TSC rate with > > a 100ms nanosleep or 1s sleep. The latter occurs more > > frequently in VMs which often do not have access to the > > data they need from arch-specific means (CPUID leaf 0x15 > > or MSR 0xCE on x86). > > > > In secondary processes, the extra 100ms is especially > > noticeable and consumes the bulk of rte_eal_init() > > execution time. To resolve this extra delay, have > > the primary process put the TSC rate into a shared > > memory region that the secondary process can lookup. > > > > Reduces rte_eal_init() execution time in a secondary > > process from 165ms to 66ms on my test system. > > > > Signed-off-by: Jim Harris > > --- > > I think this is a bad idea. If you're allocating something, you're supposed > to free it in rte_eal_cleanup(). If you don't, that memory leaks (i.e. there > are leftover hugepages after process exit). Since both primary and secondary > are referencing it (even if only at init), there is no safe way to free this > memzone. > What is the issue with not freeing it? How do we handle this for other global data to be shared?