DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] Cleanup of secondary proc fbarray files?
@ 2018-07-31 16:36 Eads, Gage
  2018-08-01  8:01 ` Burakov, Anatoly
  0 siblings, 1 reply; 3+ messages in thread
From: Eads, Gage @ 2018-07-31 16:36 UTC (permalink / raw)
  To: dev; +Cc: Burakov, Anatoly

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] Cleanup of secondary proc fbarray files?
  2018-07-31 16:36 [dpdk-dev] Cleanup of secondary proc fbarray files? Eads, Gage
@ 2018-08-01  8:01 ` Burakov, Anatoly
  2018-08-01  8:08   ` Burakov, Anatoly
  0 siblings, 1 reply; 3+ messages in thread
From: Burakov, Anatoly @ 2018-08-01  8:01 UTC (permalink / raw)
  To: Eads, Gage, dev

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().

-- 
Thanks,
Anatoly

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] Cleanup of secondary proc fbarray files?
  2018-08-01  8:01 ` Burakov, Anatoly
@ 2018-08-01  8:08   ` Burakov, Anatoly
  0 siblings, 0 replies; 3+ messages in thread
From: Burakov, Anatoly @ 2018-08-01  8:08 UTC (permalink / raw)
  To: Eads, Gage, dev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-08-01  8:08 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-31 16:36 [dpdk-dev] Cleanup of secondary proc fbarray files? Eads, Gage
2018-08-01  8:01 ` Burakov, Anatoly
2018-08-01  8:08   ` Burakov, Anatoly

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).