Re: [tbench regression fixes]: digging out smelly deadmen.

Mike Galbraith
2008-10-25T07:52:21Z

On Sat, 2008-10-25 at 00:24 -0700, David Miller wrote:
> From: Mike Galbraith <efault@gmx.de>
> Date: Sat, 25 Oct 2008 08:53:43 +0200
>
> > On Sat, 2008-10-25 at 07:58 +0200, Mike Galbraith wrote:
> > 2.6.24.7-up
> > ring-test - 1.100 us/cycle = 909 KHz (gcc-4.1)
> > ring-test - 1.068 us/cycle = 936 KHz (gcc-4.3)
> > netperf - 122300.66 rr/s = 244 KHz sb 280 KHz / 140039.03 rr/s
> > tbench - 341.523 MB/sec
> >
> > 2.6.25.17-up
> > ring-test - 1.163 us/cycle = 859 KHz (gcc-4.1)
> > ring-test - 1.129 us/cycle = 885 KHz (gcc-4.3)
> > netperf - 132102.70 rr/s = 264 KHz sb 275 KHz / 137627.30 rr/s
> > tbench - 361.71 MB/sec
> >
> > ..in 25, something happened that dropped my max context switch rate from
> > ~930 KHz to ~885 KHz. Maybe I'll have better luck trying to find that.
> > Added to to-do list. Benchmark mysteries I'm going to have to leave
> > alone, they've kicked my little butt quite thoroughly ;-)
>
> But note that tbench performance improved a bit in 2.6.25.

Yeah, netperf too.

> In my tests I noticed a similar effect, but from 2.6.23 to 2.6.24,
> weird.

23->24 I can understand. In my testing, 23 CFS was not a wonderful
experience for rapid switchers. 24 is cfs-24.1.

> Just for the public record here are the numbers I got in my testing.
> Each entry was run purely on the latest 2.6.X-stable tree for each
> release. First is the tbench score and then there are 40 numbers
> which are sparc64 cpu cycle counts of default_wake_function().

Your numbers seem to ~agree with mine. And yeah, that hrtick is damned
expensive. I didn't realize _how_ expensive until I trimmed my config
way way down from distro. Just having highres timers enabled makes a
very large difference here, even without hrtick enabled, and with the
overhead of a disabled hrtick removed.

-Mike