All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Zhihong" <zhihong.wang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling
Date: Wed, 25 Nov 2015 01:59:12 +0000	[thread overview]
Message-ID: <8F6C2BD409508844A0EFC19955BE0941835ADD@SHSMSX152.ccr.corp.intel.com> (raw)
In-Reply-To: <3179262.cyHqZdDHPg@xps13>



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, November 25, 2015 7:04 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Wang, Zhihong <zhihong.wang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] lib/librte_eal: Remove unnecessary
> hugepage zero-filling
> 
> 2015-11-24 14:44, Stephen Hemminger:
> > On Tue, 24 Nov 2015 22:13:28 +0100
> > Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> >
> > > 2015-11-22 18:28, Stephen Hemminger:
> > > > On Sun, 22 Nov 2015 14:13:35 -0500 Zhihong Wang
> > > > <zhihong.wang@intel.com> 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 <zhihong.wang@intel.com>
> > > >
> > > > Nice, especially on slow machines or with large memory.
> > > >
> > > > Acked-by: Stephen Hemminger <stephen@networkplumber.org>
> > >
> > > 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.
> 
> I mean it changes the memory allocator behaviour. It's not something we want 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 startup 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.

  parent reply	other threads:[~2015-11-25  1:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-22 19:13 [PATCH 0/2] Reduce DPDK initialization time Zhihong Wang
2015-11-22 19:13 ` [PATCH 1/2] lib/librte_eal: Reduce timer " Zhihong Wang
2015-11-22 19:13 ` [PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Zhihong Wang
2015-11-23  2:28   ` Stephen Hemminger
2015-11-24 21:13     ` Thomas Monjalon
2015-11-24 22:44       ` Stephen Hemminger
2015-11-24 23:04         ` Thomas Monjalon
2015-11-25  1:57           ` Yuanhan Liu
2015-11-25  1:59           ` Wang, Zhihong [this message]
2016-01-21 14:59 ` [PATCH 0/2] Reduce DPDK initialization time Thomas Monjalon

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=8F6C2BD409508844A0EFC19955BE0941835ADD@SHSMSX152.ccr.corp.intel.com \
    --to=zhihong.wang@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=thomas.monjalon@6wind.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.