Re: [PATCH 2/9] nsproxy: incorporate fs namespace

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

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/