From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Burakov, Anatoly" Subject: Re: Huge mapping secondary process linux Date: Fri, 27 Oct 2017 17:06:49 +0100 Message-ID: <6c60c15b-a8c1-d74d-23b3-254fa53e16cf@intel.com> References: <921d836f-87dc-b017-2186-e70905f61612@intel.com> <8fa16207-f057-d5fc-1942-54719526c837@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: bruce.richardson@intel.com, chaozhu@linux.vnet.ibm.com, dev@dpdk.org To: "Tan, Jianfeng" , Jonas Pfefferle1 Return-path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 0EFAA1BAE4 for ; Fri, 27 Oct 2017 18:06:52 +0200 (CEST) In-Reply-To: <8fa16207-f057-d5fc-1942-54719526c837@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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" wrote on 10/27/2017 >>> 04:06:44 PM: >>> >>>  > From: "Burakov, Anatoly" >>>  > To: Jonas Pfefferle1 , dev@dpdk.org >>>  > Cc: chaozhu@linux.vnet.ibm.com, bruce.richardson@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