On 9/17/07, Ingo Molnar <[email protected]> wrote: > > * Rob Hussey <[email protected]> wrote: > > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png > > heh - am i the only one impressed by the consistency of the blue line in > this graph? :-) [ and the green line looks a bit like a .. staircase? ] > > i've meanwhile tested hackbench 90 and the performance difference > between -ck and -cfs-devel seems to be mostly down to the more precise > (but slower) sched_clock() introduced in v2.6.23 and to the startup > penalty of freshly created tasks. > > Putting back the 2.6.22 version and tweaking the startup penalty gives > this: > > [hackbench 90, smaller is better] > > sched-devel.git sched-devel.git+lowres-sched-clock+dsp > --------------- -------------------------------------- > 5.555 5.149 > 5.641 5.149 > 5.572 5.171 > 5.583 5.155 > 5.532 5.111 > 5.540 5.138 > 5.617 5.176 > 5.542 5.119 > 5.587 5.159 > 5.553 5.177 > -------------------------------------- > avg: 5.572 avg: 5.150 (-8.1%) > > ('lowres-sched-clock' is the patch i sent in the previous mail. 'dsp' is > a disable-startup-penalty patch that is in the latest sched-devel.git) > > i have used your .config to conduct this test. > > can you reproduce this with the (very-) latest sched-devel git tree: > > git-pull git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git > > plus with the low-res-sched-clock patch (re-) attached below? > > Ingo > --- > arch/i386/kernel/tsc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: linux/arch/i386/kernel/tsc.c > =================================================================== > --- linux.orig/arch/i386/kernel/tsc.c > +++ linux/arch/i386/kernel/tsc.c > @@ -110,9 +110,9 @@ unsigned long long native_sched_clock(vo > * very important for it to be as fast as the platform > * can achive it. ) > */ > - if (unlikely(!tsc_enabled && !tsc_unstable)) > + if (1 || unlikely(!tsc_enabled && !tsc_unstable)) > /* No locking but a rare wrong value is not a big deal: */ > - return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ); > + return jiffies_64 * (1000000000 / HZ); > > /* read the Time Stamp Counter: */ > rdtscll(this_offset); > - Sorry it took so long for me to get back. Ok, to start the dmesg output for 2.6.22-ck1 is attached. The relevant lines seem to be: [ 27.691348] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 27.995427] Time: tsc clocksource has been installed. I've updated to the latest sched-devel git, and applied the patch above. I ran it through the same tests, but this time only while bound to a single core. Some selected numbers: lat_ctx -s 0 $i (the left most number is $i): 15 3.09 16 3.09 17 3.11 18 3.07 19 2.99 20 3.09 21 3.05 22 3.11 23 3.05 24 3.08 25 3.06 hackbench $i: 80 11.720 81 11.698 82 11.888 83 12.094 84 12.232 85 12.351 86 12.512 87 12.680 88 12.736 89 12.861 90 13.103 pipe-test (the left most number is the run #): 1 8.85 2 8.80 3 8.84 4 8.82 5 8.82 6 8.80 7 8.82 8 8.82 9 8.85 10 8.83 Once again, graphs: http://www.healthcarelinen.com/misc/benchmarks/BOUND_PATCHED_lat_ctx_benchmark.png http://www.healthcarelinen.com/misc/benchmarks/BOUND_PATCHED_hackbench_benchmark.png http://www.healthcarelinen.com/misc/benchmarks/BOUND_PATCHED_pipe-test_benchmark.png I saw in your other email that you'd like for me to try with CONFIG_PREEMPT disabled. I should have a chance to try that very soon. Regards, Rob
Attachment:
dmesg-2.6.22-ck1.bz2
Description: BZip2 compressed data
Attachment:
BOUND_PATCHED_hackbench_benchmark.png
Description: PNG image
Attachment:
BOUND_PATCHED_lat_ctx_benchmark.png
Description: PNG image
Attachment:
BOUND_PATCHED_pipe-test_benchmark.png
Description: PNG image
Attachment:
data_files2.tar.bz2
Description: BZip2 compressed data
- References:
- Scheduler benchmarks - a follow-up
- From: "Rob Hussey" <[email protected]>
- Re: Scheduler benchmarks - a follow-up
- From: Ingo Molnar <[email protected]>
- Scheduler benchmarks - a follow-up
- Prev by Date: Re: My position on general ``RAS'' tool support infrastructure
- Next by Date: Re: 2.6.20 (XFS? related) crash after uptime of > 180 days during apt-get dist-upgrade on Debian Testing
- Previous by thread: Re: Scheduler benchmarks - a follow-up
- Next by thread: Radeonfb Xpress 200M RC410 support patch
- Index(es):
 |