Re: [RFC][PATCH 0/5] uts namespaces: Introduction

[Serge E. Hallyn]

Quoting Kirill Korotaev (dev@xxxxx):
> Serge,
> 
> >This patchset is based on Kirill Korotaev's Mar 24 submission, taking
> >comments (in particular from James Morris and Eric Biederman) into
> >account.
> thanks a lot for doing this!

NP, thanks for doing the first round.

> >Some performance results are attached.  I was mainly curious whether
> >it would be worth putting the task_struct->uts_ns pointer inside
> >a #ifdef CONFIG_UTS_NS.  The result show that leaving it in when
> >CONFIG_UTS_NS=n has negligable performance impact, so that is the
> >approach this patch takes.
> Serge, your testing approach looks really strange for me.
> First of all, you selected the worst namespace to check performance 
> overhead on.
> 1) uts_ns is rarely used and never used on hot paths,
> 2) also all these test suites below doesn't test the code paths you 
> modified.
> 
> So I wonder what was the goal of these tests, especially dbench?!

Right, I wasn't actually aiming to test the performance of the uts
namespaces themselves (despite including those numbers), since they're
not on hot paths.  I was mostly curious whether putting the utsns
pointer into the task_struct would affect performance at all, to know
whether to put that inside an #ifdef.  Based on the results, I kept it
non-#ifdefed even if !CONFIG_UTS_NS, and that's what I was justifying
with those numbers.

These tests should be done again when we get 3 or 5 namespace pointers,
and perhaps there should still be some other tests included, ie mainly a
forkbomb perhaps.  I just did my default set of tests that I usually
use.

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/