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.

> 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 :) 

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@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

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@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers

[ ... ]

>>> 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?

I'll take a look. 

Thanks,

C.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers