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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> - 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 [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]
  Powered by Linux