Eric W. Biederman wrote: > Pavel Emelianov <[EMAIL PROTECTED]> writes: > >> Hi Eric, Suka, guys. >> >> I have tested the following configurations: >> >> 1. 2.6.21-mm2 kernel with Suka's patches with CONFIG_PID_NS=n >> 2. the same with CONFIG_PID_NS=y >> >> 3. 2.6.22-rc1-mm1 kernel with my own realisation (patches will >> be sent later if interesting) with CONFIG_PID_NS=n; >> 4. the same with CONFIG_PID_NS=y and flat model (OpenVZ view) >> I sent earlier; >> 5. the same with multilevel model of my own. The difference is >> that I use hash to lookup pid_elem from struct pid/pid_t nr, >> not a plain "for" loop like in Suka's patches. > > For small levels of nesting a for loop should actually be faster.
Nope. I thought the same when worked on OpenVZ RSS fractions accounting and found out that loop and hash lookup are almost the same even for one-element-length list. I don't know what the problem is exactly but since then I tend to measure my guesses. > These tests were all taken in the initial pid namespace? > Yes. You mention that below. > >> The tests run were: >> 1. Unixbench spawn test >> 2. Unixbench execl test >> 3. Unixbensh shell test >> 4. System time for ps -xaf run in a loop (1000 times) > > If these test accurately measure what the purport to measure > these appear to fair, and useful for discussion. Although we may have > cache hot vs cache cold effects doing weird things to us. > > These results need to be reproduced. > > We need to get all of the patches against the same kernel > so we can truly have an apples to apples comparison. > > The rough number of pids in the system when the tests are taken needs > to be known. Sure. cat /proc/slabinfo | grep pid shows ~500 pids/pid+1upids on each kernel (roughly) before the tests. >> The hardware used is 2x Intel(R) Xeon(TM) CPU 3.20GHz box with >> 2Gb of RAM. All the results are reproducible with 0.1% accuracy. >> The slowdown is shown in comparison to the according results for >> CONFIG_PID_NS=n kernel. >> >> Summary: >> Suka's model gives us about 1.5% of overhead. >> My multilevel model gives us about 0.7% of overhead. >> My flat model gives us an overhead comparative to >> the accuracy of the measurement, i.e. zero overhead. >> >> The detailed results are the following: >> Test name: spawn execl shell ps (sys time) >> 1(no ns) : 579.1 618.3 1623.2 3.052s >> 2(suka's): 570.7 610.8 1600.2 3.107s >> Slowdown : 1.5% 1.3% 1.4% 1.8% >> >> 3(no ns) : 580.6 616.0 1633.8 3.050s >> 4(flat) : 580.8 615.1 1632.2 3.054s >> Slowdown : 0% 0.1% <0.1% 0.1% >> 5(multi) : 576.9 611.0 1618.8 3.065s >> Slowdown : 0.6% 0.8% 0.9% 0.5% > > Just for my own amusement. Of course - the base kernels differ. >> 1(no ns) : 579.1 618.3 1623.2 3.052s >> 3(no ns) : 580.6 616.0 1633.8 3.050s > -0.25% 0.3% -0.65% 0.065% Not - but + - the larger the number is the better the result is. I emphasize - the results of namespaces patches were get against *the base kernel*. I.e. Suka's patches slow down 2.6.21 by 1.5%. My patches with flat model slowdown the 2.6.22 kernel by 0%. I believe that the flat model will slowdown even 2.6.21 kernel for 0%, but Suka's - even 2.6.22 by somewhat similar (about 1-2%). Yet again: the intention of my measurements are not to prove my multilevel model is better than Suka's one, but to prove that the *flat* model is faster than multilevel one and thus must be present in the kernel as well. > >> For the first three tests the result is better the higher the >> number is. For the last test - the result is better the lower the >> number is (since it is a time spent in kernel). >> >> The results in the namespace may be worse. >> >> If you are interested I can send my patches for pre-review and >> cooperation. With the results shown I think the we do must have >> the flat model as an option in the kernel for those who don't >> need the infinite nesting, but cares for the kernel performance. > > Your results do seem to indicate there is measurable overhead, > although in all cases it is slight. So if we care about performance > we need to look at things very carefully. This is slight for init namespace. In sub-namespace the results may be worse. IMHO 1.5% is significant enough. 1.5% here and 0.4% there and 0.6% over there and we have Xen overhead after all :) And no way to find out what has happened. > Eric > Thank, Pavel _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel