From: "Varghese, Vipin" <vipin.varghese@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] eal: clean up unused files on initialization
Date: Wed, 14 Nov 2018 03:24:11 +0000 [thread overview]
Message-ID: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2BE984@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <821e4582-5594-d291-6047-d6e5ba7b120f@intel.com>
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.
>
> --
> Thanks,
> Anatoly
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.
Thanks
Vipin Varghese
next prev parent reply other threads:[~2018-11-14 3:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 15:29 [dpdk-stable] [PATCH] " Anatoly Burakov
2018-11-13 15:54 ` [dpdk-stable] [PATCH v2] " Anatoly Burakov
2018-11-13 16:57 ` [dpdk-stable] [dpdk-dev] " Thomas Monjalon
2018-11-13 17:47 ` Burakov, Anatoly
2018-11-14 3:24 ` Varghese, Vipin [this message]
2018-11-14 3:44 ` Thomas Monjalon
2018-11-14 10:20 ` Burakov, Anatoly
2018-12-19 3:13 ` Thomas Monjalon
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=4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2BE984@BGSMSX101.gar.corp.intel.com \
--to=vipin.varghese@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/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).