From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: Cleanup of secondary proc fbarray files?
Date: Wed, 1 Aug 2018 09:08:17 +0100
Message-ID: <8998f634-3b26-17dd-b840-285f2d0833ab@intel.com>
References: <9184057F7FC11744A2107296B6B8EB1E446F5E4D@FMSMSX108.amr.corp.intel.com>
 <71fb8cbc-cdc2-f1c7-dca9-ecbfac42e453@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
To: "Eads, Gage" <gage.eads@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 975F858FE
 for <dev@dpdk.org>; Wed,  1 Aug 2018 10:08:20 +0200 (CEST)
In-Reply-To: <71fb8cbc-cdc2-f1c7-dca9-ecbfac42e453@intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 01-Aug-18 9:01 AM, Burakov, Anatoly wrote:
> On 31-Jul-18 5:36 PM, Eads, Gage wrote:
>> As far as I can tell, DPDK does not destroy secondary process fbarray 
>> files – i.e. those whose names end with “_<PID>”. With enough 
>> secondary processes and memory usage per application, and after enough 
>> repeat executions, these can take up a significant amount of space. Is 
>> the user expected to clean these up themselves, or is this a bug in DPDK?
>>
>> Perhaps this is a good candidate for including in rte_eal_cleanup()?
>>
>> Thanks,
>>
>> Gage
>>
> 
> Good point, this was my omission. This should be done in eal_cleaup().
> 
Actually, it should probably be done at fbarray allocation :) We put a 
lock on those files, so those that are unlocked we know can be removed 
safely. We do the same for hugetlbfs files at init. I will submit a 
patch for this for 18.11 some time later.

-- 
Thanks,
Anatoly