Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 04 May 2012 00:55:44 -0700 | Subject | Re: [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
| |