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

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Andi Kleen (ak@suse.de):
> On Tuesday 02 May 2006 10:03, Eric W. Biederman wrote:
> 7 additional bits will probably not be enough. I still don't
> quite understand why you want individual bits for everything.
> Why not group them into logical pieces? 

I wouldn't be surprised if it makes sense to combine some of them.  For
instance, perhaps utsname and networking?

> Have a proxy structure which has pointers to the many name spaces and a bit
> mask for "namespace X is different".

different from what?

Oh, you mean in case we want to allow cloning a namespace outside of
fork *without* cloning the nsproxy struct?

> 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.

Still, like Eric, I'm fine with trying that approach.  It just doesn't
seem like we can draw any meaningful conclusions with just one namespace
pointer, and adding a separate reference counted object around the
utsname pointer would seem to just make the code harder to review.

> 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.

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/