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 2BE09A0613 for ; Tue, 27 Aug 2019 16:00:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9B9E81C124; Tue, 27 Aug 2019 16:00:10 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id C31F51C122 for ; Tue, 27 Aug 2019 16:00:08 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 07:00:07 -0700 X-IronPort-AV: E=Sophos;i="5.64,437,1559545200"; d="scan'208";a="192233609" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 07:00:05 -0700 Date: Tue, 27 Aug 2019 15:00:03 +0100 From: Bruce Richardson To: "Burakov, Anatoly" Cc: Jim Harris , dev@dpdk.org Message-ID: <20190827140002.GA614@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. > Actually, after looking at the code again, the secondary processes only reference the memzone once on init, and fallback to the current path if the memzone does not exist. Therefore, it should be safe to remove the memzone on termination of the primary process.