Messages in this thread |  | | | Subject | Re: [tbench regression fixes]: digging out smelly deadmen. | | From | Mike Galbraith <> | | Date | Sat, 25 Oct 2008 09:52:02 +0200 |
| |
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
|  |