[Devel] Re: [PATCH 0/28] Pid namespaces (two models)

[Herbert Poetzl]

On Tue, Jun 19, 2007 at 04:00:09PM -0700, Andrew Morton wrote:
> On Fri, 15 Jun 2007 19:55:43 +0400
> Pavel Emelianov <xemul at openvz.org> wrote:
> 
> > Long ago Sukadev and I sent two approaches for pid namespaces - the
> > hierarchical model in which namespaces are nested into each other,
> > and the flat model, where pids have only two values and creation of
> > level 3 namespace is prohibited.
> > 
> > After that I showed that multilevel model introduces a noticeable
> > overhead of approximately 1-2% to kernel standard operations like
> > fork() and getpid(). At the same time flat model showed no performance
> > hit on these tests.
> > 
> > Nevertheless multilevel model is worth living.
> > 
> > This set introduces booth models each under its config option. The
> > set is logically splitted into the following parts:
> 
> Making this configurable sounds like a very bad idea to me, from the
> maintainablility/testability/understandability POV.
> 
> We should just make up our minds and do it one way, do it right?
> 
> I assume that means hierarchical.  
> 
> > The following tests were run:
> > [1] nptl perf test
> > [2] getpid() speed
> > [3] ltp (not for speed, but for kernel API checks)
> > 
> > The testing results summary:
> > * Flat model provides zero overhead in init namespace for all the 
> > tests and less than 7% in the namespace for nptl test only.

why do we see 7% overhead in nptl tests?
any idea what actually causes that?

TIA,
Herbert

> > * Multilevel model provides up to 2% overhead in init namespace and
> > more than 10% for nptl test in the level 2 namespace.
> > 
> 
> So that means we take a 3% hit in these operations when PID_NS_MULTILEVEL
> is enabled but the system isn't using containers at all?
> 
> If so, I'm surprised that the cost is this high.  This should be the first
> thing we should optimise and I bet there's some quicky way of doing it.
> 
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers