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):
>> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>> 
>> 
>> > @@ -1727,11 +1727,16 @@ static void __init init_mount_tree(void)
>> >  	namespace->root = mnt;
>> >  	mnt->mnt_namespace = namespace;
>> >  
>> > -	init_task.namespace = namespace;
>> > +	init_task.nsproxy->namespace = namespace;
>> >  	read_lock(&tasklist_lock);
>> >  	do_each_thread(g, p) {
>> > +		/* do we want namespace count to be #nsproxies,
>> > +		 * or # processes pointing to the namespace? */
>> 
>> I am fairly certain we want the count to be #nsproxies.
>> 
>> >  		get_namespace(namespace);
>> > -		p->namespace = namespace;
>> > +#if 0
>> > +		/* should only be 1 nsproxy so far */
>> > +		p->nsproxy->namespace = namespace;
>> > +#endif
>> >  	} while_each_thread(g, p);
>> >  	read_unlock(&tasklist_lock);
>> 
>> So I think this bit is wrong.
>
> Ok - in that case I need to audit the rest of namespace usage to make
> certain nothing depends on the count being #tasks.

Ok.  Thats makes sense.

> BTW - a first set of comparison results showed nsproxy to have better
> dbench and tbench throughput, and worse kernbench performance.  Which
> may make sense given that nsproxy results in lower memory usage but
> likely increased cache misses due to extra pointer dereference.

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.

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

Eric