Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH 7/7] uts namespaces: Implement CLONE_NEWUTS flag | Date | Tue, 2 May 2006 19:30:44 +0200 |
| |
On Tuesday 02 May 2006 19:20, Serge E. Hallyn wrote: > 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?
I frankly would just combine everything new.
> > > 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.
> > > 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.
> > 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 the opinion memory/cache bloat needs to be attacked at the root, not when it's too late.
-Andi - 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/
| |