lkml.org 
[lkml]   [2012]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure
    Mike Galbraith <efault@gmx.de> writes:

    > Namespaces have something in common with cgroups. synchronize_rcu()
    > makes them somewhat less than wonderful for dynamic use.

    Well unlike cgroups namespaces were not designed for heavy dynamic use.
    Although it appears that vsftp puts them to that kind of use so some
    of the design decisions are with revisiting.

    > default flags = SIGCHLD
    >
    > -namespace: flag |= CLONE_NEWPID
    > -all: flags |= CLONE_NEWIPC | CLONE_NEWNET | CLONE_NEWUSER
    >
    > marge:/usr/local/tmp/starvation # ./hackbench
    > Running with 10*40 (== 400) tasks.
    > Time: 2.636
    > marge:/usr/local/tmp/starvation # ./hackbench -namespace
    > Running with 10*40 (== 400) tasks.
    > Time: 11.624
    > marge:/usr/local/tmp/starvation # ./hackbench -namespace -all
    > Running with 10*40 (== 400) tasks.
    > Time: 51.474

    CLONE_NEWUSER? I presume you have applied my latest user namespace
    patches? Otherwise you are running completely half baked code.

    hackbench? Which kernel are you running. Hackbench in some kernels is
    really good at triggering cache ping-pong effects with pids, and creds.
    So I'm not certain what to say there. In the latest kernels things
    should be better with unix domain sockets as long as you don't actually
    ask to pass your creds but hackbench is still a pretty ridiculous
    benchmark. Oversharing is always going to be bad for performance.

    > You can create trash quickly, but you have to haul it away.

    Well synchronize_rcu is much better in that respect than call_rcu, which
    let's the trash build up but is never carried away.

    The core design assumption with namespaces is that they will be used
    much more than they will be created/destroyed, and as long as there are
    progress guarantees in place I don't have a problem with that. At the
    same time if there are easy things we can do to make things go faster
    I am in favor of that notion.

    Still especially in the case of hackbench I think it is worth asking the
    question how much of the slow down is due to cache ping-pong due to
    oversharing.

    Eric


    \
     
     \ /
      Last update: 2012-05-04 10:01    [W:0.062 / U:363.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site