OpenVZ Forum - RDF feed
type: channel
items: Re: nptl perf bench and profiling with pidns patchsets
items: Re: Re: nptl perf bench and profiling with pidns patchsets

Re: nptl perf bench and profiling with pidns patchsets
type: item
description: Quoting Kirill Korotaev (dev@sw.ru): > Cedric, > > just a small note. > imho it is not correct to check performance with enabled debug in memory allocator > since it can influence cache efficiency much. > In you case looks like you have DEBUG_SLAB enabled. Hm, good point. Cedric, did you ever run any tests with profiling and debugging turned off? -serge > Pavel will recheck as well what influences on this particular test. > BTW, it is strange... But according to Pavel unixbench results > were very reproducible. What was the problem in your case? > > Kirill > > Cedric Le Goater wrote: > > Pavel and all, > > > > I've been profiling the different pidns patchsets to chase the perf > > bottlenecks in the pidns patchset. As i was not getting accurate > > profiling results with unixbench, I changed the benchmark to use the > > nptl perf benchmark ingo used when he introduced the generic pidhash > > back in 2002. > > > > http://lwn.net/Articles/10368/ > > > > Compared to unixbench, this is a micro benchmark measuring thread > > creation and destruction which I think is quite relevant of our > > different patchsets. unixbench is fine but profiling is not really > > accurate. too much noise. Any other suggestions ? > > > > On a 2 * Intel(R) Xeon(TM) CPU 2.80GHz with 4 GB of RAM, I ran 8 > > simultaneous, like ingo did : > > > > ./perf -s 1000000 -t 1 -r 0 -T --sync-join > > > > I did that a few times and also changed the load of the machine > > to see if values were not too dispersed. > > > > kernels used were : > > > > * 2.6.22-rc1-mm1 > > * http://lxc.sourceforge.net/patches/2.6.22/2.6.22-rc1-mm1-openvz-pidns1/ > > * http://lxc.sourceforge.net/patches/2.6.22/2.6.22-rc1-mm1-pidns1/ > > > > findings are : > > > > * definitely better results for suka's patchset. suka's patchset is > > also getting better results with unixbench on a 2.6.22-rc1-mm1 but > > the values are really dispersed. can you confirm ? > > * suka's patchset would benefit from some optimization in init_upid()…
creator: serue
date: 2007-06-04T13:56:05-00:00

Re: Re: nptl perf bench and profiling with pidns patchsets
type: item
description: Serge E. Hallyn wrote: > Quoting Kirill Korotaev (dev@sw.ru): >> Cedric, >> >> just a small note. >> imho it is not correct to check performance with enabled debug in memory allocator >> since it can influence cache efficiency much. >> In you case looks like you have DEBUG_SLAB enabled. > > Hm, good point. Cedric, did you ever run any tests with profiling and > debugging turned off? I'd like to add that the results-for-comparison have to be run with profiler turned off. Further, if we need to know what the bottleneck is, the profiler is on, but the numbers get are not trusted. Cedric, may I ask you to rerun the tests with both the debug and the profiler turned off and report the results again? Thanks, Pavel > -serge > >> Pavel will recheck as well what influences on this particular test. >> BTW, it is strange... But according to Pavel unixbench results >> were very reproducible. What was the problem in your case? >> >> Kirill >> >> Cedric Le Goater wrote: >>> Pavel and all, >>> >>> I've been profiling the different pidns patchsets to chase the perf >>> bottlenecks in the pidns patchset. As i was not getting accurate >>> profiling results with unixbench, I changed the benchmark to use the >>> nptl perf benchmark ingo used when he introduced the generic pidhash >>> back in 2002. >>> >>> http://lwn.net/Articles/10368/ >>> >>> Compared to unixbench, this is a micro benchmark measuring thread >>> creation and destruction which I think is quite relevant of our >>> different patchsets. unixbench is fine but profiling is not really >>> accurate. too much noise. Any other suggestions ? >>> >>> On a 2 * Intel(R) Xeon(TM) CPU 2.80GHz with 4 GB of RAM, I ran 8 >>> simultaneous, like ingo did : >>> >>> ./perf -s 1000000 -t 1 -r 0 -T --sync-join >>> >>> I did that a few times and also changed the load of the machine >>> to see if values were not too dispersed. >>> >>> kernels used were : >>> >>> * 2.6.22-rc1-mm1 >>> * http://lxc.sourceforge.net/patches/2.6.22/2.6.22-rc1-mm1-openv…
creator: xemul
date: 2007-06-04T14:12:06-00:00

Re: Re: nptl perf bench and profiling with pidns patchsets
type: item
description: Pavel Emelianov wrote: > Serge E. Hallyn wrote: >> Quoting Kirill Korotaev (dev@sw.ru): >>> Cedric, >>> >>> just a small note. >>> imho it is not correct to check performance with enabled debug in memory allocator >>> since it can influence cache efficiency much. >>> In you case looks like you have DEBUG_SLAB enabled. >> Hm, good point. Cedric, did you ever run any tests with profiling and >> debugging turned off? > > I'd like to add that the results-for-comparison have to be run > with profiler turned off. Further, if we need to know what the > bottleneck is, the profiler is on, but the numbers get are not > trusted. > > Cedric, may I ask you to rerun the tests with both the debug and > the profiler turned off and report the results again? sure. let me do all debug=off first because i'm interested in some figures. so what do you think of the nptl perf benchmark to evaluate our progress ? C. _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Cedric Le Goater
date: 2007-06-04T14:17:27-00:00

Re: Re: nptl perf bench and profiling with pidns patchsets
type: item
description: Cedric Le Goater wrote: > Pavel Emelianov wrote: >> Serge E. Hallyn wrote: >>> Quoting Kirill Korotaev (dev@sw.ru): >>>> Cedric, >>>> >>>> just a small note. >>>> imho it is not correct to check performance with enabled debug in memory allocator >>>> since it can influence cache efficiency much. >>>> In you case looks like you have DEBUG_SLAB enabled. >>> Hm, good point. Cedric, did you ever run any tests with profiling and >>> debugging turned off? >> I'd like to add that the results-for-comparison have to be run >> with profiler turned off. Further, if we need to know what the >> bottleneck is, the profiler is on, but the numbers get are not >> trusted. >> >> Cedric, may I ask you to rerun the tests with both the debug and >> the profiler turned off and report the results again? > > sure. let me do all debug=off first because i'm interested in some > figures. Just to be sure. When I tested the namespaces I made the node clean from any daemon that could spoil the results and made the cache hot for the files involved in testing. Otherwise the results could have more than 5% of accuracy which is not enough... > so what do you think of the nptl perf benchmark to evaluate our > progress ? If this is just a spawn test for threads, then I think this is not enough. This test *is* important, but we have to check some more issues when talking about the namespaces. I will look at this test closer tomorrow for more competent answer. > C. Thanks, Pavel _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: xemul
date: 2007-06-04T14:31:04-00:00