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

From: Serge E. Hallyn
Date: Wed May 10 2006 - 16:34:34 EST


Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/