Linux Container Development
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
To: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Dmitry V. Levin" <ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>,
	Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	KOSAKI Motohiro
	<kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"Kirill A. Shutemov"
	<kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Pavel Emelyanov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH v2] ns: do not block exit_task_namespaces() for a long time
Date: Mon, 16 Jul 2012 20:16:34 +0300	[thread overview]
Message-ID: <20120716171634.GA21620@shutemov.name> (raw)
In-Reply-To: <20120716165301.GN31729-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>

On Mon, Jul 16, 2012 at 05:53:01PM +0100, Al Viro wrote:
> On Mon, Jul 16, 2012 at 06:09:24PM +0300, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov" <kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > 
> > On exiting of the last task in a namespace we need to trigger freeing of
> > the namespace. Currently, we call synchronize_rcu() and free_nsproxy()
> > directly on do_exit() path.
> > 
> > On my machine synchronize_rcu() blocks for about 0.01 seconds. For
> > comparing: normal exit_group() syscall takes less than 0.0003 seconds.
> > 
> > Let's offload synchronize_rcu() and free_nsproxy() to a workqueue.
> > 
> > I also move synchronize_rcu() inside free_nsproxy(). It fixes racy
> > put_nsproxy() which calls free_nsproxy() without synchronize_rcu().
> > I guess it was missed during switch to RCU (see cf7b708).
> 
> NAK.  Making final umounts of anything in that namespace asynchronous,
> even though nothing is holding the stuff on them busy is simply
> wrong.  Note that they can take a _long_ time, so we are talking about
> minutes worth of delay in the worst case.  It's user-visible and
> it's a serious potential for trouble.

Good point.

Now in worst case we have a process which hang for a few minutes in
exit_group() syscall in D state, right? Why is that any better?
Does it provide better user experience or better accounting or what?

-- 
 Kirill A. Shutemov

  parent reply	other threads:[~2012-07-16 17:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13 11:48 [PATCH] ns: move free_nsproxy() out of do_exit() path Kirill A. Shutemov
     [not found] ` <1342180088-22647-1-git-send-email-kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2012-07-13 21:08   ` Andrew Morton
     [not found]     ` <20120713140806.b3d0fda8.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-07-13 22:23       ` Kirill A. Shutemov
2012-07-16 15:09       ` [PATCH v2] ns: do not block exit_task_namespaces() for a long time Kirill A. Shutemov
     [not found]         ` <1342451364-14787-1-git-send-email-kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2012-07-16 15:39           ` Myklebust, Trond
2012-07-16 16:53           ` Al Viro
     [not found]             ` <20120716165301.GN31729-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2012-07-16 17:16               ` Kirill A. Shutemov [this message]
     [not found]                 ` <20120716171634.GA21620-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
2012-07-16 17:22                   ` Al Viro
2012-07-16 21:05           ` Kirill A. Shutemov
     [not found]         ` <1342453174.4648.6.camel@lade.trondhjem.org>
     [not found]           ` <1342453174.4648.6.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
2012-07-16 16:39             ` Kirill A. Shutemov
2012-07-16 16:53               ` Myklebust, Trond

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=20120716171634.GA21620@shutemov.name \
    --to=kirill-okw7cidhh8elwutg50ltga@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=kirill.shutemov-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org \
    --cc=ldv-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    --cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    /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