From: "Chao Zhu" <chaozhu@linux.vnet.ibm.com>
To: "'Sergio Gonzalez Monroy'" <sergio.gonzalez.monroy@intel.com>,
<dev@dpdk.org>
Cc: "'Gowrishankar'" <gowrishankar.m@linux.vnet.ibm.com>,
<david.marchand@6wind.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] eal/ppc: fix mmap for memory initialization
Date: Thu, 13 Apr 2017 09:40:00 +0800 [thread overview]
Message-ID: <000401d2b3f6$e8047a60$b80d6f20$@linux.vnet.ibm.com> (raw)
In-Reply-To: <4de077b0-6ca4-2905-ec09-e1a200cda1b0@intel.com>
Sergio,
Thanks for the comments!
On POWER, if it doesn't specify the MAP_HUGETLB flag when doing mapping, it
may get the addresses from other regions. However, the address space size of
hugepages is exactly the same as the value specified by user when doing
initialization. There will be not enough space for mmap twice in DPDK.
That's why we need to set the overcommit to expand the address space.
> -----Original Message-----
> From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.monroy@intel.com]
> Sent: 2017年4月6日 20:59
> To: Chao Zhu <chaozhu@linux.vnet.ibm.com>; dev@dpdk.org
> Cc: Gowrishankar <gowrishankar.m@linux.vnet.ibm.com>;
> david.marchand@6wind.com
> Subject: Re: [PATCH 1/2] eal/ppc: fix mmap for memory initialization
>
> Hi Chao,
>
> You mentioned that 'mmap will not respect the requested address hint', how
> does the proposed change solves that?
>
> Is it that hugepages map to a specific VA region, and without MAP_HUGETLB
> you may get address from wrong region?
>
> If mmap were to respect the hinted address, we could do this change
> multi-arch without having to set overcommit hugepages?
>
> fd = -1
> addr = mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE |
> MAP_ANONYMOUS | MAP_HUGETLB, fd, 0) # Free hugepages mapping addr =
> mmap(addr, (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE |
> MAP_ANONYMOUS, fd, 0)
>
> What do you think?
>
> Regards,
> Sergio
>
> On 06/04/2017 11:06, Chao Zhu wrote:
> > On IBM POWER platform, when mapping /dev/zero file to hugepage memory
> > space, mmap will not respect the requested address hint. This will
> > cause the memory initilization for the second process fails. This
> > patch adds the required mmap flags to make it work. Beside this, users
> > need to set the nr_overcommit_hugepages to expand the VA range. When
> > doing the initilization, users need to set both nr_hugepages and
> > nr_overcommit_hugepages to the same value, like 64, 128, etc.
> >
> > Signed-off-by: Chao Zhu <chaozhu@linux.vnet.ibm.com>
> > ---
> > lib/librte_eal/linuxapp/eal/eal_memory.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> > b/lib/librte_eal/linuxapp/eal/eal_memory.c
> > index a956bb2..e06186b 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> > @@ -313,7 +313,11 @@ int rte_xen_dom0_supported(void)
> > }
> > do {
> > addr = mmap(addr,
> > +#ifndef RTE_ARCH_PPC_64
> > (*size) + hugepage_sz, PROT_READ,
MAP_PRIVATE, fd,
> 0);
> > +#else
> > + (*size) + hugepage_sz, PROT_READ, MAP_PRIVATE |
> > +MAP_ANONYMOUS | MAP_HUGETLB, fd, 0); #endif
> > if (addr == MAP_FAILED)
> > *size -= hugepage_sz;
> > } while (addr == MAP_FAILED && *size > 0); @@ -1330,7 +1334,11
> @@
> > static int huge_wrap_sigsetjmp(void)
> > * use mmap to get identical addresses as the primary
process.
> > */
> > base_addr = mmap(mcfg->memseg[s].addr,
> mcfg->memseg[s].len,
> > +#ifndef RTE_ARCH_PPC_64
> > PROT_READ, MAP_PRIVATE, fd_zero, 0);
> > +#else
> > + PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS |
> > +MAP_HUGETLB, fd_zero, 0); #endif
> > if (base_addr == MAP_FAILED ||
> > base_addr != mcfg->memseg[s].addr) {
> > max_seg = s;
>
next prev parent reply other threads:[~2017-04-13 1:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 10:06 [dpdk-dev] [PATCH 0/2] ppc:Fix the memory initialization for IBM POWER Chao Zhu
2017-04-06 10:06 ` [dpdk-dev] [PATCH 1/2] eal/ppc: fix mmap for memory initialization Chao Zhu
2017-04-06 12:58 ` Sergio Gonzalez Monroy
2017-04-13 1:40 ` Chao Zhu [this message]
2017-04-13 8:14 ` Sergio Gonzalez Monroy
2017-04-20 7:41 ` Thomas Monjalon
2017-04-20 7:39 ` Thomas Monjalon
2017-04-06 10:06 ` [dpdk-dev] [PATCH 2/2] doc/guides: Add hugepage reserve instructions for IBM POWER Chao Zhu
2017-04-06 16:16 ` Mcnamara, John
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='000401d2b3f6$e8047a60$b80d6f20$@linux.vnet.ibm.com' \
--to=chaozhu@linux.vnet.ibm.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=gowrishankar.m@linux.vnet.ibm.com \
--cc=sergio.gonzalez.monroy@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).