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    [W:0.028 / U:1.712 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site