From: "Serge E. Hallyn" <serge@hallyn.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Dmitry V. Levin" <ldv@altlinux.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Doug Ledford <dledford@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, serge@hallyn.com,
"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [RFC, PATCH] CLONE_NEWIPC and exit_group()
Date: Tue, 26 Jun 2012 17:55:14 +0000 [thread overview]
Message-ID: <20120626175514.GA32248@mail.hallyn.com> (raw)
In-Reply-To: <20120626174542.GA15482@otc-wbsnb-06>
Quoting Kirill A. Shutemov (kirill.shutemov@linux.intel.com):
> On Tue, Jun 26, 2012 at 05:04:57PM +0000, Serge E. Hallyn wrote:
> > Quoting Kirill A. Shutemov (kirill.shutemov@linux.intel.com):
> > > Hi,
> > >
> > > Patch to move kern_unmount() out of exit_group() code path is below.
> > > Dmitry, could you check if it's beneficial for your use-case?
> >
> > Hi,
> >
> > sorry, I don't seem to have the thread handy for contest. What is the
> > point of this? The work being moved was not being done under lock,
> > so what is this meant to gain?
>
> It's basically addition to this patch (tested with the patch applied):
>
> http://thread.gmane.org/gmane.linux.kernel.cifs/6347/focus=23929
>
> Some context: Dmitry has workload which run a lot of short-living tasks in
> sandboxed environment. He noticed that exit_group() syscall of the last
> process in IPC namespace is a bottleneck.
>
> The bottleneck was mainly due rcu_barrier() in kern_umount(). It's fixed
> by patch in the link (Andrew took it in -mm).
>
Ah I see, thanks.
> But probably having kern_umount() in exit_group() code path is not a good
> idea from scalability point of view?..
OTOH, does doing that mean that the extra processing time is (correctly)
accounted to the exiting user? Just a thought. But your argument also
makes sense, and I see no problem with the patch, so
Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
thanks,
-serge
next prev parent reply other threads:[~2012-06-26 17:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 12:04 [RFC, PATCH] CLONE_NEWIPC and exit_group() Kirill A. Shutemov
2012-06-26 17:04 ` Serge E. Hallyn
2012-06-26 17:45 ` Kirill A. Shutemov
2012-06-26 17:55 ` Serge E. Hallyn [this message]
2012-06-27 12:34 ` Dmitry V. Levin
2012-06-27 13:01 ` Serge Hallyn
2012-07-10 8:50 ` Kirill A. Shutemov
2012-07-11 22:24 ` Andrew Morton
2012-07-12 15:07 ` Kirill A. Shutemov
2012-07-12 18:54 ` Serge Hallyn
2012-07-12 19:06 ` Doug Ledford
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=20120626175514.GA32248@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=akpm@linux-foundation.org \
--cc=dledford@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=ldv@altlinux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.