"Serge E. Hallyn" <[email protected]> writes:
> Quoting Eric W. Biederman ([email protected]):
>> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
