Re: [PATCH 7/7] uts namespaces: Implement CLONE_NEWUTS flag

[Herbert Poetzl]

On Wed, May 03, 2006 at 11:11:43AM -0500, Serge E. Hallyn wrote:
> Quoting Andi Kleen (ak@xxxxxxx):
> > On Tuesday 02 May 2006 19:20, Serge E. Hallyn wrote:
> > > Quoting Andi Kleen (ak@xxxxxxx):
> > > > Have a proxy structure which has pointers to the many name spaces and a bit
> > > > mask for "namespace X is different".
> > > 
> > > different from what?
> > 
> > From the parent.
> 
> ...
> 
> > > Oh, you mean in case we want to allow cloning a namespace outside of
> > > fork *without* cloning the nsproxy struct?
> > 
> > Basically every time any name space changes you need a new nsproxy.
> 
> But, either the nsproxy is shared between tasks and you need to copy
> youself a new one as soon as any ns changes, or it is not shared, and
> you don't need  that info at all (just make the change in the nsproxy
> immediately)
> 
> What am I missing?
> 
> Should we talk about this  on irc someplace?  Perhaps drag in Eric as
> well?

good idea, feel free to use #vserver (irc.oftc.net) for that

> > > > This structure would be reference
> > > > counted. task_struct has a single pointer to it.
> > > 
> > > If it is reference counted, that implies it is shared between some
> > > processes.  But namespace pointers themselves are shared between some of
> > > these nsproxy's.  The lifetime mgmt here is one reason I haven't tried a
> > > patch to do this.
> > 
> > The livetime management is no different from having individual pointers.
> 
> That's true if we have one nsproxy per process or thread, which I didn't
> think was the case.  Are you saying not to share nsproxy's among
> processes which share all namespaces?
> 
> > > > With many name spaces you would have smaller task_struct, less cache 
> > > > foot print, better cache use of task_struct because slab cache colouring
> > > > will still work etc.
> > > 
> > > I suppose we could run some performance tests with some dummy namespace
> > > pointers?  9 void *'s directly in the task struct, and the same inside a
> > > refcounted container struct.  The results might add some urgency to
> > > implementing the struct nsproxy.
> > 
> > Not sure you'll notice too much difference on the beginning. I am just
> 
> 9 void*'s is probably more than we'll need, though, so it's not "the
> beginning".   Eric previously mentioned uts, sysvipc, net, pid, and uid,
> to which we might add proc, sysctl, and signals, though those are
> probably just implied through the others.

> What others do you see us needing?

the 'container', as well as accounting and resource limits
but they are not required in the beginning either

> If the number were more likely to be 50, then in the above experiment
> use 50 instead - the point was to see the performance implications
> without implementing the namespaces first.
> 
> Anyway I guess I'll go ahead and queue up some tests.

good!

best,
Herbert

> > the opinion memory/cache bloat needs to be attacked at the root, not
> > when it's too late.
> 
> -serge
-
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/