Messages in this thread | | | Date | Tue, 11 Apr 2006 09:01:46 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH 0/5] uts namespaces: Introduction |
| |
Quoting Kirill Korotaev (dev@sw.ru): > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |