Messages in this thread | | | Date | Wed, 10 May 2006 15:34:49 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH 2/9] nsproxy: incorporate fs namespace |
| |
Quoting Eric W. Biederman (ebiederm@xmission.com): > There are two additional things I can think of that are worth looking > at: > - moving copy_uts_namespace, and copy_namespace inside of copy_nsproxy > so we only run those we create a new nsproxy instance.
Was about to do that when I stopped because I was thinking I'd need to keep track of which namespace had been copied before a failaure, for the sake of clone.
But of course I don't have to - copy_nsproxy could do the cleanup itself on failure.
So this should be a nice little cleanup - especially as # namespaces increases.
> - Attempting to optimize cache line utilization by placing the > structures in line in struct ns_proxy: > struct nsproxy { > atomic_t count; > struct namespace *namespace; > struct uts_namespace *uts_ns; > struct namespace namespace_data; > struct new_utsname uts_data; > }; > With the nsproxy count severing as a count for both the embedded > data and for the nsproxy itself. I think it is a long shot but it > could be interesting. > > Given the frequency of use of the uts namespace and the filesystem > namespace simply I think not accessing those namespaces on fork is > likely to reduce the additional cache line miss rate enough so > that it is lost in the noise.
Not getting this. Are you saying the uts_data would be a copy of the contents of *uts_ns, or that uts_ns points to nsproxy->uts_data? If the latter, then just unsharing uts_ns but not mounts namespace is no longer possible, right?
thanks, -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/
| |