All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@canonical.com>
To: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.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,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [RFC, PATCH] CLONE_NEWIPC and exit_group()
Date: Wed, 27 Jun 2012 08:01:25 -0500	[thread overview]
Message-ID: <20120627130125.GA23431@sergelap> (raw)
In-Reply-To: <20120627123455.GA32171@altlinux.org>

Quoting Dmitry V. Levin (ldv@altlinux.org):
> Hi,
> 
> On Tue, Jun 26, 2012 at 03:04:26PM +0300, Kirill A. Shutemov wrote:
> > 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?
> 
> I've benchmarked a slightly modified test which is closer to our use-case
> (child processes are forked sequentially):

Did you run this in parallel, perhaps with numcpus/2 jobs plus a
hackbench running on the side?

> #define _GNU_SOURCE
> #include <unistd.h>
> #include <sched.h>
> #include <stdlib.h>
> #include <sys/wait.h>
> 
> int
> main(void)
> {
> 	int i;
> 	for (i = 0; i < 1024; i++) {
> 		if (fork()) {
> 			wait(NULL);
> 			continue;
> 		}
> 		unshare(CLONE_NEWIPC);
> 		exit(0);
> 	}
> 	return 0;
> }
> 
> On 3.4.4 with rcu_barrier patch:
> 0.09user 0.00system 0:32.77elapsed 0%CPU (0avgtext+0avgdata 1472maxresident)k
> 0inputs+0outputs (0major+38017minor)pagefaults 0swaps
> 
> On 3.4.4 with rcu_barrier patch and your new patch:
> 0.00user 0.06system 0:32.77elapsed 0%CPU (0avgtext+0avgdata 1472maxresident)k
> 0inputs+0outputs (0major+38017minor)pagefaults 0swaps
> 
> So there is a clear difference in accounting (user vs system)

Yup, I'd argue that's a bad thing :)

> but no
> noticeable difference in the real time.

Thanks for testing!

-serge

  reply	other threads:[~2012-06-27 13:01 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
2012-06-27 12:34 ` Dmitry V. Levin
2012-06-27 13:01   ` Serge Hallyn [this message]
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=20120627130125.GA23431@sergelap \
    --to=serge.hallyn@canonical.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.