Messages in this thread | | | Subject | Re: [PATCH 2/9] nsproxy: incorporate fs namespace | From | (Eric W. Biederman) | Date | Wed, 10 May 2006 13:07:39 -0600 |
| |
"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 - 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/
| |