Cedric Le Goater wrote: > Pavel Emelianov wrote: >> OK. We have measured the nptl perf test for init namespace. >> Summary - flat model is very light, Suka's patches break the >> kernel performance event when CONFIG_PID_NS is off. >> >> | perf, s | perf loss | >> -----------------+--------------+------------+ >> 2.6.22-rc4-mm2 | 13.79 ± 0.13 | --- | >> | | | >> suka + PID_NS=n | 14.07 ± 0.13 | 2.0% | >> suka + PID_NS=y | 14.06 ± 0.08 | 2.0% | >> | | | >> pavel + PID_NS=n | 13.80 ± 0.07 | 0.0% | >> pavel + FLAT | 13.80 ± 0.07 | 0.0% | >> pavel + MULTI | 14.28 ± 0.08 | 3.5% | >> -----------------+--------------+------------+ > > is that on the same hardware you used last time ? > 2 * Intel(R) Xeon(TM) CPU 3.00GHz with 2GB RAM. Yup. >> I do believe that Suka's hierarchical model is better than mine, >> but my point is: let's support the flat model as well. > > OK. First thing we can do is to find what they have in common and > get that included. Then, after the first round, we might even find > some more to reach the MULTI model :) The [PREP xxx] series of patches does exactly this. It has the proc changes, all the necessary things to work with pid numbers, all the preparations in kernel/pid.c, signal handling, etc. Do you mind using this? The [MULTI xxx] series is just a demonstration of how this model can be done above my patches. I saw that Suka's model was faster (and I think I know why) so I'm fine with throwing out my multilevel model (only). > That said, I'm perfectly fine with the FLAT model, because I think > it covers nearly all the real world scenarii i know about : system > containers, application containers. > > C. > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers