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

[ebiederm@xmission.com (Eric W. Biederman)]

"Serge E. Hallyn" <serue@us.ibm.com> writes:

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

Yes.  At least if nsproxy doesn't show a performance degradation...

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

The latter, uts_ns normally points to nsproxy->uts_data.  But it still
remains possible to unshare just the mounts namespace by simply coping
the pointer when we clone nsproxy, and incrementing the previous
ns_proxies count.

Like I said I think it is a long shot but if the data for namespaces
really does remain small and they are usually all unshared in a group
it could be a win.

Eric

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