From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 27 Oct 2017 09:06:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,304,1505804400"; d="scan'208";a="168507790" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.210.134]) ([10.237.210.134]) by fmsmga006.fm.intel.com with ESMTP; 27 Oct 2017 09:06:50 -0700 To: "Tan, Jianfeng" , Jonas Pfefferle1 Cc: bruce.richardson@intel.com, chaozhu@linux.vnet.ibm.com, dev@dpdk.org References: <921d836f-87dc-b017-2186-e70905f61612@intel.com> <8fa16207-f057-d5fc-1942-54719526c837@intel.com> From: "Burakov, Anatoly" Message-ID: <6c60c15b-a8c1-d74d-23b3-254fa53e16cf@intel.com> Date: Fri, 27 Oct 2017 17:06:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8fa16207-f057-d5fc-1942-54719526c837@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] Huge mapping secondary process linux X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 16:06:53 -0000 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