lkml.org 
[lkml]   [2012]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure
From
Date
On Fri, 2012-05-04 at 07:13 -0700, Eric W. Biederman wrote: 
> Mike Galbraith <efault@gmx.de> writes:
>
> > On Fri, 2012-05-04 at 00:55 -0700, Eric W. Biederman wrote:
> >
> >> CLONE_NEWUSER? I presume you have applied my latest user namespace
> >> patches? Otherwise you are running completely half baked code.
> >
> > I Removed CLONE_NEWUSER flag.
> >
> >> hackbench? Which kernel are you running. Hackbench in some kernels is
> >> really good at triggering cache ping-pong effects with pids, and creds.
> >
> > Not when pinned. 3.0 kernel without the debug stuff enabled in 3.4.git.
> >
> > marge:/usr/local/tmp/starvation # taskset -c 3 ./hackbench
> > Running with 10*40 (== 400) tasks.
> > Time: 0.868
> > marge:/usr/local/tmp/starvation # taskset -c 3 ./hackbench -namespace
> > Running with 10*40 (== 400) tasks.
> > Time: 7.582
> > marge:/usr/local/tmp/starvation # taskset -c 3 ./hackbench -namespace -all
> > Running with 10*40 (== 400) tasks.
> > Time: 29.677
>
> Interesting. I guess what truly puzzles me is what serializes all of
> the processes. Even synchronize_rcu should sleep and thus let other
> synchronize_rcu calls run in parallel.
>
> Did you have HZ=100 in that kernel? 400 tasks at 100Hz all serialized
> somehow and then doing synchronize_rcu at a jiffy each would account
> for 4 seconds. And the nsproxy certainly has a synchronize_rcu call.

HZ=250

> The network namespace is comparatively heavy weight, at least in the
> amount of code and other things it has to go through, so that would be
> my prime suspect for those 29 seconds. There are 2-4 synchronize_rcu
> calls needed to put the loopback device. Still we use
> synchronize_rcu_expedited and that work should be out of line and all of
> those calls should batch.
>
> Mike is this something you are looking at a pursuing farther?

Not really, but I can put it on my good intentions list.

> I want to guess the serialization comes from waiting on children to be
> reaped but the namespaces are all cleaned up in exit_notify() called
> from do_exit() so that theory doesn't hold water. The worst case
> I can see is detach_pid from exit_signal running under the task list lock.
> but nothing sleeps under that lock. :(

I'm up to my ears in zombies with several instances of the testcase
running in parallel, so I imagine it's the same with hackbench.

marge:/usr/local/tmp/starvation # taskset -c 3 ./hackbench -namespace& for i in 1 2 3 4 5 6 7 ; do ps ax|grep defunct|wc -l;sleep 1; done
[1] 29985
Running with 10*40 (== 400) tasks.
1
397
327
261
199
135
72
marge:/usr/local/tmp/starvation # Time: 7.675
-Mike



\
 
 \ /
  Last update: 2012-05-04 17:01    [from the cache]
©2003-2011 Jasper Spaans