Re: Scheduler benchmarks - a follow-up

From: Rob Hussey
Date: Mon Sep 17 2007 - 21:44:55 EST

On 9/17/07, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> * Rob Hussey <robjhussey@xxxxxxxxx> 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