From: "Jonas Pfefferle" <pepperjo@japf.ch>
To: "Xueming(Steven) Li" <xuemingl@mellanox.com>,
"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: [PATCH] mem: warn if address hint is not respected
Date: Wed, 03 Jan 2018 10:22:22 +0100 [thread overview]
Message-ID: <web-40976788@switchplus-mail.ch> (raw)
In-Reply-To: <VI1PR0502MB40796C075232EDC5B0550349AC060@VI1PR0502MB4079.eurprd05.prod.outlook.com>
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:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 9:08 [PATCH] mem: warn if address hint is not respected 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 [this message]
2018-01-03 9:37 ` Xueming(Steven) Li
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=web-40976788@switchplus-mail.ch \
--to=pepperjo@japf.ch \
--cc=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=thomas@monjalon.net \
--cc=xuemingl@mellanox.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.