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? ]

Looks lovely, though as long as lower is better, that staircase does a
nice job ;-)

quoted text
> 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%)

Hmmm. So cfs was 0.8% slower compared to ck in the test by Rob, it
became 8% faster so... it should be faster than CK - provided these
results are valid over different tests.

But this is all microbenchmarks, which won't have much effect in real
life, right? Besides, will the lowres sched clock patch get in?

quoted text
> ('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);
> _______________________________________________
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: ck@vds.kolivas.org
> http://vds.kolivas.org/mailman/listinfo/ck
>
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/