On 9/17/07, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
> * Rob Hussey <robjhussey@gmail.com> 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