DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	"Varghese, Vipin" <vipin.varghese@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] [PATCH v2] eal: clean up unused files on initialization
Date: Wed, 14 Nov 2018 10:20:08 +0000	[thread overview]
Message-ID: <e9787daf-92c6-6ae0-1230-240d929ccdb9@intel.com> (raw)
In-Reply-To: <2137402.5xZ7V9L5Yp@xps>

On 14-Nov-18 3:44 AM, Thomas Monjalon wrote:
> 14/11/2018 04:24, Varghese, Vipin:
>> Tested-by: Vipin Varghese <vipin.varghese@intel.com>
>>
>> <snipped>
>>   
>>>>> When creating process data structures, EAL will create many files in
>>>>> EAL runtime directory. Because we allow multiple secondary processes
>>>>> to run, each secondary process gets their own unique file. With many
>>>>> secondary processes running and exiting on the system, runtime
>>>>> directory will, over time, create enormous amounts of sockets,
>>>>> fbarray files and other stuff that just sits there unused because the
>>>>> process that allocated it has died a long time ago. This may lead to
>>>>> exhaustion of disk (or RAM) space in the runtime directory.
>>>>>
>>>>> Fix this by removing every unlocked file at initialization that
>>>>> matches either socket or fbarray naming convention. We cannot be sure
>>>>> of any other files, so we'll leave them alone. Also, remove similar
>>>>> code from mp socket code.
>>>>>
>>>>> We do it at the end of init, rather than at the beginning, because
>>>>> secondary process will use primary process' data structures even if
>>>>> the primary itself has died, and we don't want to remove those before
>>>>> we lock them.
>>>>>
>>>>> Bugzilla ID: 106
>>>>>
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Reported-by: Vipin Varghese <vipin.varghese@intel.com>
>>>>>
>>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>>
>> Thanks Anatoly for the patch which clean-ups the tmpfs. This unblock the client from critical stopper too.
>>
>>>>
>>>> I feel it is too big and too late for 18.11.
>>>> Can we move it to 19.02?
>>>
>>>   From maintainer's point of view, i agree that it's too risky to merge into 18.11
>>> at this stage. My input should probably stop there, but Vipin (the original bug
>>> reporter) may have other thoughts on this matter.
>>
>> Hi Thomas, without the fix it affects both dpdk and non dpdk application use a host or VM. My suggestion to have the fix in and port to 18.11 LTS too.
> 
> It is changing a behaviour.
> I propose to test it on 19.02 and backport it in 18.11.1.
> 
> Any other opinion?
> 

That would probably be the best compromise IMO.

-- 
Thanks,
Anatoly

  reply	other threads:[~2018-11-14 10:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 15:29 [dpdk-dev] [PATCH] " Anatoly Burakov
2018-11-13 15:54 ` [dpdk-dev] [PATCH v2] " Anatoly Burakov
2018-11-13 16:57   ` Thomas Monjalon
2018-11-13 17:47     ` Burakov, Anatoly
2018-11-14  3:24       ` Varghese, Vipin
2018-11-14  3:44         ` Thomas Monjalon
2018-11-14 10:20           ` Burakov, Anatoly [this message]
2018-12-19  3:13   ` Thomas Monjalon
2018-11-14 15:59 Eads, Gage

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9787daf-92c6-6ae0-1230-240d929ccdb9@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=vipin.varghese@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).