Re: [PATCH] Re: [RFC PATCH] namespaces: fix leak on fork() failure

[Eric W. Biederman]

Mike Galbraith <efault@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/