[dpdk-dev] Huge mapping secondary process linux

[Burakov, Anatoly]

On 27-Oct-17 4:48 PM, Tan, Jianfeng wrote:
> 
> 
> On 10/27/2017 10:44 PM, Burakov, Anatoly wrote:
>> On 27-Oct-17 3:28 PM, Jonas Pfefferle1 wrote:
>>> "Burakov, Anatoly" <anatoly.burakov at intel.com> wrote on 10/27/2017 
>>> 04:06:44 PM:
>>>
>>>  > From: "Burakov, Anatoly" <anatoly.burakov at intel.com>
>>>  > To: Jonas Pfefferle1 <JPF at zurich.ibm.com>, dev at dpdk.org
>>>  > Cc: chaozhu at linux.vnet.ibm.com, bruce.richardson at intel.com
>>>  > Date: 10/27/2017 04:06 PM
>>>  > Subject: Re: [dpdk-dev] Huge mapping secondary process linux
>>>  ...
>>>  > >
>>>  > hi Jonas,
>>>  >
>>>  > MAP_FIXED is not used because it's dangerous, it unmaps anything 
>>> that is
>>>  > already mapped into that space. We would rather know that we can't 
>>> map
>>>  > something than unwittingly unmap something that was mapped before.
>>>
>>> Ok, I see. Maybe we can add a check to the primary process's memory 
>>> mappings whether the hint has been respected or not? At least warn if 
>>> it hasn't.
>>
>> Hi Jonas,
>>
>> I'm unfamiliar with POWER platform, so i'm afraid you'd have to 
>> explain a bit more what you mean by "hint has been respected" :)
> 
> Actually, I also met this case on x86 once that kernel does not respect 
> the "addr" parameter even that memory region is not occupied. I am not 
> sure if it can be reproduced now, anyway, send here FYI: we run primary 
> on the host, run secondary in a container.
> 
> I'll agree at least we need to check if the final addr is the same of 
> the parameter addr, and warn if it's not.
> 
> Thanks,
> Jianfeng
> 

We could put in a warning saying that the address we got is *lower* than 
the address we expected to get, but i'm not sure throwing a warning 
because our assumption about kernel's behavior was incorrect is worth it.

-- 
Thanks,
Anatoly