"Serge E. Hallyn" <[email protected]> writes:
> Quoting Eric W. Biederman ([email protected]):
>> "Serge E. Hallyn" <[email protected]> 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 [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]
