From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 744EC8E5A for ; Thu, 1 Oct 2015 10:41:24 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 01 Oct 2015 01:41:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,616,1437462000"; d="scan'208";a="816935746" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.61]) by fmsmga002.fm.intel.com with SMTP; 01 Oct 2015 01:41:22 -0700 Received: by (sSMTP sendmail emulation); Thu, 01 Oct 2015 09:41:20 +0025 Date: Thu, 1 Oct 2015 09:41:20 +0100 From: Bruce Richardson To: "shesha Sreenivasamurthy (shesha)" Message-ID: <20151001084120.GA15796@bricha3-MOBL3> References: <20150929161628.GA3810@redhat.com> <20150930003531-mutt-send-email-mst@redhat.com> <2601191342CEEE43887BDE71AB97725836AA21E7@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" , "Michael S. Tsirkin" Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2015 08:41:25 -0000 On Wed, Sep 30, 2015 at 10:04:36PM +0000, shesha Sreenivasamurthy (shesha) wrote: > My bad that I said its not working, apologies. > > Isn’t it correct to say that single process application do not benefit from having backing files ? In that case can make this configurable by passing a command line argument that will either unlink or keep the backing files, defaulting it to keeping the backing files. Single process application to do not need these files around can pass additional param to unlink these files ? > Sure. Or else the user can just use rm after starting the application. Or the application itself can also remove the files after starting up. There is no reason that this needs to be done by the EAL :-) /Bruce > -- > - Thanks > char * (*shesha) (uint64_t cache, uint8_t F00D) > { return 0x0000C0DE; } > > From: "Ananyev, Konstantin" > > Date: Wednesday, September 30, 2015 at 2:53 PM > To: Cisco Employee >, "dev@dpdk.org" > > Cc: "Michael S. Tsirkin" > > Subject: RE: [dpdk-dev] Unlinking hugepage backing file after initialiation > > > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of shesha Sreenivasamurthy (shesha) > Sent: Wednesday, September 30, 2015 10:44 PM > To: dev@dpdk.org > Cc: Michael S. Tsirkin > Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation > What I heard is the following: A multi-process DPDK application, working either in master-worker or master-slave fashion, can > potentially benefit by keeping the backing files in hugetlbfs. However, it is does not work today as the pages are cleaned and added > back when the application restarts. > > Who says it is not working? > I admit that DPDK MP model is probably a bit constrained, but it does work. > It is probably good to read some docs: > http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html > and/or look at the code that does MP support inside DPDK. > I think that might make things clearer. > Konstantin > > On the other hand, for a single process application there is actually no benefit keeping the pages > around. > Therefore, I was wondering if we can make this configurable by passing a command line argument that will either unlink or keep the > backing files. > -- > - Thanks > char * (*shesha) (uint64_t cache, uint8_t F00D) > { return 0x0000C0DE; } > From: "Michael S. Tsirkin" > > Date: Tuesday, September 29, 2015 at 2:35 PM > To: Cisco Employee > > Cc: "Xie, Huawei" >, "dev@dpdk.org" > > > Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation > On Tue, Sep 29, 2015 at 05:50:00PM +0000, shesha Sreenivasamurthy (shesha) wrote: > Sure. Then, is there any real reason why the backing files should not be > unlinked ? > AFAIK qemu unlinks them already. > -- > MST > >