DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Zhihong" <zhihong.wang@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove	unnecessary hugepage zero-filling
Date: Thu, 19 Nov 2015 02:15:24 +0000	[thread overview]
Message-ID: <8F6C2BD409508844A0EFC19955BE0941834A76@SHSMSX152.ccr.corp.intel.com> (raw)
In-Reply-To: <20151118110906.3e0b3dcd@samsung9>



> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger
> Sent: Thursday, November 19, 2015 3:09 AM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary
> hugepage zero-filling
> 
> On Wed, 18 Nov 2015 16:13:32 +0000
> "Richardson, Bruce" <bruce.richardson@intel.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen
> > > Hemminger
> > > Sent: Wednesday, November 18, 2015 4:00 PM
> > > To: Xie, Huawei <huawei.xie@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove
> > > unnecessary hugepage zero-filling
> > >
> > > On Wed, 18 Nov 2015 12:07:54 +0000
> > > "Xie, Huawei" <huawei.xie@intel.com> wrote:
> > >
> > > > >>> The kernel fills new allocated (huge) pages with zeros.
> > > > >>> DPDK just has to touch the pages to trigger the allocation.
> > > > I think we shouldn't reply on the assumption that kernel has
> > > > zeroed the memory. Kernel zeroes the memory mostly to avoid
> > > > information leakage.It could also achieve this by setting each bit to 1.
> > > > What we indeed need to check is later DPDK initialization code
> > > > doesn't assume the memory has been zeroed. Otherwise zero only
> > > > that part of the memory. Does this makes sense?
> > >
> > > If all new pages are zero, why does DPDK have to pre-touch the pages
> > > at all?
> >
> > The pages won't actually be mapped into the processes address space until
> accessed.
> >
> > /Bruce
> 
> Isn't that what mmap MAP_POPULATE flag (not currently used) will do.

Yes, the MAP_POPULATE does literally the same thing.
This flag is implemented since Linux 2.5.46 according to Linux man page, guess that's why DPDK fault the page tables manually in the first place. :)

I think we can use this flag since it makes the code clearer.

/Zhihong

  reply	other threads:[~2015-11-19  2:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-18  3:27 [dpdk-dev] [RFC PATCH 0/2] Reduce DPDK initialization time Zhihong Wang
2015-11-18  3:27 ` [dpdk-dev] [RFC PATCH 1/2] lib/librte_eal: Reduce timer " Zhihong Wang
2015-11-18  3:27 ` [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Zhihong Wang
2015-11-18 10:39   ` Mcnamara, John
2015-11-18 10:44     ` Wang, Zhihong
2015-11-18 12:07       ` Xie, Huawei
2015-11-18 16:00         ` Stephen Hemminger
2015-11-18 16:13           ` Richardson, Bruce
2015-11-18 19:09             ` Stephen Hemminger
2015-11-19  2:15               ` Wang, Zhihong [this message]
2015-11-19  6:04                 ` Xie, Huawei
2015-11-19  6:32                   ` Wang, Zhihong
2015-11-19  9:18                     ` Sergio Gonzalez Monroy
2015-11-23  2:54                     ` Xie, Huawei
2015-11-23 10:18                       ` Bruce Richardson
2015-11-20 12:15               ` Bruce Richardson
2015-11-19  3:54         ` Wang, Zhihong
2015-11-19  6:09           ` Xie, Huawei
2015-11-19  9:14         ` Sergio Gonzalez Monroy
2015-11-23  3:46           ` Xie, Huawei
2015-11-23  4:07             ` Stephen Hemminger
2015-11-23  5:05               ` Xie, Huawei
2015-11-23  6:52                 ` Stephen Hemminger
2015-11-25 18:24                   ` Xie, Huawei
2015-12-24  8:34 ` [dpdk-dev] [RFC PATCH 0/2] Reduce DPDK initialization time Qiu, Michael

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=8F6C2BD409508844A0EFC19955BE0941834A76@SHSMSX152.ccr.corp.intel.com \
    --to=zhihong.wang@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /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).