All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Varghese, Vipin" <vipin.varghese@intel.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>,
	ferruh.yigit@intel.com
Subject: Re: [PATCH v2] eal: clean up unused files on initialization
Date: Wed, 14 Nov 2018 04:44:20 +0100	[thread overview]
Message-ID: <2137402.5xZ7V9L5Yp@xps> (raw)
In-Reply-To: <4C9E0AB70F954A408CC4ADDBF0F8FA7D4D2BE984@BGSMSX101.gar.corp.intel.com>

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?

  reply	other threads:[~2018-11-14  3:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-13 15:29 [PATCH] eal: clean up unused files on initialization Anatoly Burakov
2018-11-13 15:54 ` [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 [this message]
2018-11-14 10:20           ` Burakov, Anatoly
2018-12-19  3:13   ` Thomas Monjalon
  -- strict thread matches above, loose matches on Subject: below --
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=2137402.5xZ7V9L5Yp@xps \
    --to=thomas@monjalon.net \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stable@dpdk.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.