From: "Xueming(Steven) Li" <xuemingl@mellanox.com>
To: Jonas Pfefferle <pepperjo@japf.ch>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"jianfeng.tan@intel.com" <jianfeng.tan@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH] mem: warn if address hint is not respected
Date: Wed, 3 Jan 2018 09:37:00 +0000 [thread overview]
Message-ID: <VI1PR0502MB407942A65DB65DA880622676AC1E0@VI1PR0502MB4079.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <web-40976788@switchplus-mail.ch>
So the idea of item 3 might sound and lead to seldom usage of '--base-virtaddress'.
Reserve an address hole big enough before hugepage almost cost nothing.
> -----Original Message-----
> From: Jonas Pfefferle [mailto:pepperjo@japf.ch]
> Sent: Wednesday, January 3, 2018 5:22 PM
> To: Xueming(Steven) Li <xuemingl@mellanox.com>; Burakov, Anatoly
> <anatoly.burakov@intel.com>
> Cc: dev@dpdk.org; jianfeng.tan@intel.com; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH] mem: warn if address hint is not respected
>
> Hi Xueming,
>
> Correct --base-virtaddr was introduced for that purpose. There are
> multiple reasons why the address layout of the secondary process might
> look different: reasons you mentioned in 2), ASLR etc. I believe there is
> no way to avoid this in real world use cases. The reason for this
> particular patch is that the address hint (--base-virtaddr) is sometimes
> not respected and the kernel falls back to just reserving any address it
> can find to satisfy the mapping (see discussion on the patch), i.e.
> effectively rendering --base-virtaddr useless.
>
> Regards,
> Jonas (new email address)
>
>
> On Tue, 26 Dec 2017 15:56:10 +0000
> "Xueming(Steven) Li" <xuemingl@mellanox.com> wrote:
> > Hi Jonas,
> >
> > Seems you are trying to use --base-virtaddr to resolve address
> >conflicts in secondary, I'm wondering how this happened and how to
> >avoid it:
> > 1. what's your hugepage side? Hugepage mmap is size aligned, maybe 1G
> >works?
> > 2. is there more libs loaded in secondary process or memory usage
> >before EAL init?
> > 3. Since address allocated in one direction, I'm thinking to reserve a
> >larger "hop" address space as MAP_ANONYMOUS, allocate hugepage, then
> >release "hop". That essentially reserve an address space big enough
> >for secondary, and most important the hop size is easy to estimate
> >than --base-virtaddr.
> >
> > Thanks,
> > Xueming(Steven)
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jonas
> >>Pfefferle1
> >> Sent: Wednesday, November 8, 2017 7:52 PM
> >> To: Burakov, Anatoly <anatoly.burakov@intel.com>
> >> Cc: dev@dpdk.org; jianfeng.tan@intel.com; Thomas Monjalon
> >><thomas@monjalon.net>
> >> Subject: Re: [dpdk-dev] [PATCH] mem: warn if address hint is not
> >>respected
> >>
> >> "Burakov, Anatoly" <anatoly.burakov@intel.com> wrote on 11/07/2017
> >> 02:54:24
> >> PM:
> >>
> >> > From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
> >> > To: Thomas Monjalon <thomas@monjalon.net>
> >> > Cc: dev@dpdk.org, Jonas Pfefferle <jpf@zurich.ibm.com>,
> >> jianfeng.tan@intel.com
> >> > Date: 11/07/2017 02:54 PM
> >> > Subject: Re: [dpdk-dev] [PATCH] mem: warn if address hint is not
> >> respected
> >> >
> >> > On 06-Nov-17 8:26 PM, Thomas Monjalon wrote:
> >> > > 31/10/2017 10:08, Jonas Pfefferle:
> >> > >> Print a warning if the --base-virtaddr hint is not respected
> >>since
> >> > >> this might lead to problems when mapping memory in the
> >>secondary
> >> > >> process.
> >> > >>
> >> > >> Signed-off-by: Jonas Pfefferle <jpf@zurich.ibm.com>
> >> > >
> >> > > Anatoly, please review this patch.
> >> > > It does not seem to fix something, so it is candidate for 18.02.
> >> > >
> >> >
> >> > For some reason my Thunderbird ate the original email, so i'll
> >>reply
> >> > to this one.
> >> >
> >> > One nitpick would be that we're calling get_virtual_area many
> >>times
> >> > and it would probably be a good idea to make pagesize static and
> >>call
> >> > sysconf only once. Otherwise,
> >>
> >> We should address this in a separate patch and introduce a pagesize
> >>function for everyone to use. sysconf is used like this all over the
> >>place.
> >>
> >> >
> >> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >> >
> >> > --
> >> > Thanks,
> >> > Anatoly
> >> >
next prev parent reply other threads:[~2018-01-03 9:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 9:08 Jonas Pfefferle
2017-11-06 20:26 ` Thomas Monjalon
2017-11-07 13:54 ` Burakov, Anatoly
2017-11-08 11:51 ` Jonas Pfefferle1
2017-12-26 15:56 ` Xueming(Steven) Li
2018-01-03 9:22 ` Jonas Pfefferle
2018-01-03 9:37 ` Xueming(Steven) Li [this message]
2018-01-03 9:55 ` Jonas Pfefferle
2018-01-11 23:36 ` 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=VI1PR0502MB407942A65DB65DA880622676AC1E0@VI1PR0502MB4079.eurprd05.prod.outlook.com \
--to=xuemingl@mellanox.com \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=pepperjo@japf.ch \
--cc=thomas@monjalon.net \
/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).