DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Jim Harris <james.r.harris@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v5] eal: use memzone to share tsc hz with secondary processes
Date: Tue, 27 Aug 2019 15:00:03 +0100	[thread overview]
Message-ID: <20190827140002.GA614@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <a88a02d3-5c67-ed1e-306c-339067dfdc4c@intel.com>

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 <james.r.harris@intel.com>
> > ---
> 
> 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.

  parent reply	other threads:[~2019-08-27 14:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22  8:42 [dpdk-dev] [PATCH v3] timer: use rte_mp_msg to get freq from primary process Jim Harris
2019-08-26 13:39 ` [dpdk-dev] [PATCH v4] eal: use memzone to share tsc hz with secondary processes Jim Harris
2019-08-26 13:44 ` [dpdk-dev] [PATCH v5] " Jim Harris
2019-08-27  8:14   ` Bruce Richardson
2019-08-27 12:04   ` Burakov, Anatoly
2019-08-27 12:48     ` Bruce Richardson
2019-08-28  9:01       ` Burakov, Anatoly
2019-08-27 14:00     ` Bruce Richardson [this message]
2019-08-27 16:16 ` [dpdk-dev] [PATCH v6] eal: add tsc_hz to rte_mem_config Jim Harris
2019-10-07 15:28 ` [dpdk-dev] [PATCH v6 RESEND] " Jim Harris
2019-10-08  8:38   ` Bruce Richardson
2019-10-21  8:23     ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190827140002.GA614@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=james.r.harris@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).