![]() | |||||||||||||
Messages in this thread |
On Wed, May 03, 2006 at 11:11:43AM -0500, Serge E. Hallyn wrote: > Quoting Andi Kleen (ak@suse.de): > > On Tuesday 02 May 2006 19:20, Serge E. Hallyn wrote: > > > Quoting Andi Kleen (ak@suse.de): > > > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-05-05 06:47 [from the cache] ©2003-2008 | |||||||||||||