From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Mike Galbraith <efault@gmx.de>
Cc: Jiri Kosina <jkosina@suse.cz>, David Miller <davem@davemloft.net>,
rjw@sisk.pl, Ingo Molnar <mingo@elte.hu>,
s0mbre@tservice.net.ru, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.
Date: Sun, 26 Oct 2008 10:00:48 +0100 [thread overview]
Message-ID: <1225011648.27415.4.camel@twins> (raw)
In-Reply-To: <1225010790.8566.22.camel@marge.simson.net>
On Sun, 2008-10-26 at 09:46 +0100, Mike Galbraith wrote:
> On Sun, 2008-10-26 at 01:10 +0200, Jiri Kosina wrote:
> > On Sat, 25 Oct 2008, David Miller wrote:
> >
> > > But note that tbench performance improved a bit in 2.6.25.
> > > In my tests I noticed a similar effect, but from 2.6.23 to 2.6.24,
> > > weird.
> > > Just for the public record here are the numbers I got in my testing.
> >
> > I have been currently looking at very similarly looking issue. For the
> > public record, here are the numbers we have been able to come up with so
> > far (measured with dbench, so the absolute values are slightly different,
> > but still shows similar pattern)
> >
> > 208.4 MB/sec -- vanilla 2.6.16.60
> > 201.6 MB/sec -- vanilla 2.6.20.1
> > 172.9 MB/sec -- vanilla 2.6.22.19
> > 74.2 MB/sec -- vanilla 2.6.23
> > 46.1 MB/sec -- vanilla 2.6.24.2
> > 30.6 MB/sec -- vanilla 2.6.26.1
> >
> > I.e. huge drop for 2.6.23 (this was with default configs for each
> > respective kernel).
> > 2.6.23-rc1 shows 80.5 MB/s, i.e. a few % better than final 2.6.23, but
> > still pretty bad.
> >
> > I have gone through the commits that went into -rc1 and tried to figure
> > out which one could be responsible. Here are the numbers:
> >
> > 85.3 MB/s for 2ba2d00363 (just before on-deman readahead has been merged)
> > 82.7 MB/s for 45426812d6 (before cond_resched() has been added into page
> > 187.7 MB/s for c1e4fe711a4 (just before CFS scheduler has been merged)
> > invalidation code)
> >
> > So the current bigest suspect is CFS, but I don't have enough numbers yet
> > to be able to point a finger to it with 100% certainity. Hopefully soon.
> I reproduced this on my Q6600 box. However, I also reproduced it with
> 2.6.22.19. What I think you're seeing is just dbench creating a
> massive train wreck.
wasn't dbench one of those non-benchmarks that thrives on randomness and
unfairness?
Andrew said recently:
"dbench is pretty chaotic and it could be that a good change causes
dbench to get worse. That's happened plenty of times in the past."
So I'm not inclined to worry too much about dbench in any way shape or
form.
next prev parent reply other threads:[~2008-10-26 9:00 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 23:17 [tbench regression fixes]: digging out smelly deadmen Evgeniy Polyakov
2008-10-10 5:40 ` Peter Zijlstra
2008-10-10 8:09 ` Evgeniy Polyakov
2008-10-10 9:15 ` Ingo Molnar
2008-10-10 11:31 ` Evgeniy Polyakov
2008-10-10 11:40 ` Ingo Molnar
2008-10-10 13:25 ` Evgeniy Polyakov
2008-10-10 11:42 ` Ingo Molnar
2008-10-10 11:55 ` Evgeniy Polyakov
2008-10-10 11:57 ` Ingo Molnar
2008-10-24 22:25 ` Rafael J. Wysocki
2008-10-24 23:31 ` David Miller
2008-10-25 4:05 ` Mike Galbraith
2008-10-25 5:15 ` David Miller
2008-10-25 5:53 ` Mike Galbraith
2008-10-25 11:13 ` Rafael J. Wysocki
2008-10-26 3:55 ` David Miller
2008-10-26 11:33 ` Rafael J. Wysocki
2008-10-25 3:37 ` Mike Galbraith
2008-10-25 5:16 ` David Miller
2008-10-25 5:58 ` Mike Galbraith
2008-10-25 6:53 ` Mike Galbraith
2008-10-25 7:24 ` David Miller
2008-10-25 7:52 ` Mike Galbraith
2008-10-25 23:10 ` Jiri Kosina
2008-10-26 8:46 ` Mike Galbraith
2008-10-26 9:00 ` Peter Zijlstra [this message]
2008-10-26 9:11 ` Andrew Morton
2008-10-26 9:27 ` Evgeniy Polyakov
2008-10-26 9:34 ` Andrew Morton
2008-10-26 10:05 ` Evgeniy Polyakov
2008-10-27 2:34 ` David Miller
2008-10-27 9:30 ` Ingo Molnar
2008-10-27 9:57 ` David Miller
2008-10-26 10:23 ` Mike Galbraith
2008-10-26 19:03 ` Jiri Kosina
2008-10-27 9:29 ` Mike Galbraith
2008-10-27 10:42 ` Jiri Kosina
2008-10-27 11:27 ` Ingo Molnar
2008-10-27 11:33 ` Alan Cox
2008-10-27 12:06 ` Mike Galbraith
2008-10-27 13:42 ` Jiri Kosina
2008-10-27 14:17 ` Mike Galbraith
2008-10-27 18:33 ` Ingo Molnar
2008-10-27 19:39 ` Evgeniy Polyakov
2008-10-27 19:48 ` David Miller
2008-10-28 10:24 ` Mike Galbraith
2008-10-28 10:37 ` Ingo Molnar
2008-10-28 10:57 ` Mike Galbraith
2008-10-28 11:02 ` Ingo Molnar
2008-10-28 14:00 ` Mike Galbraith
2008-10-28 15:22 ` Mike Galbraith
2008-10-29 9:14 ` Evgeniy Polyakov
2008-10-29 9:50 ` Evgeniy Polyakov
2008-11-01 12:51 ` Paolo Ciarrocchi
2008-10-29 9:59 ` Nick Piggin
2008-10-26 9:15 ` Mike Galbraith
2008-10-25 7:19 ` David Miller
2008-10-25 7:33 ` Mike Galbraith
2008-10-27 17:26 ` Rick Jones
2008-10-27 19:11 ` Mike Galbraith
2008-10-27 19:18 ` Rick Jones
2008-10-27 19:44 ` Mike Galbraith
2008-10-26 11:29 ` Evgeniy Polyakov
2008-10-26 12:23 ` Evgeniy Polyakov
2008-10-30 18:15 ` Stephen Hemminger
2008-10-30 18:40 ` Evgeniy Polyakov
2008-10-30 18:43 ` Eric Dumazet
2008-10-30 18:56 ` Eric Dumazet
2008-10-30 19:01 ` Ilpo Järvinen
2008-10-31 7:52 ` David Miller
2008-10-31 9:40 ` Ilpo Järvinen
2008-10-31 9:51 ` David Miller
2008-10-31 10:42 ` Ilpo Järvinen
2008-10-31 10:45 ` Eric Dumazet
2008-10-31 11:01 ` Ilpo Järvinen
2008-10-31 11:10 ` Eric Dumazet
2008-10-31 11:15 ` Ilpo Järvinen
2008-10-31 19:57 ` Stephen Hemminger
2008-10-31 20:10 ` Evgeniy Polyakov
2008-10-31 21:03 ` Eric Dumazet
2008-10-31 21:18 ` Evgeniy Polyakov
2008-10-31 23:51 ` David Miller
2008-10-31 23:56 ` Stephen Hemminger
2008-11-01 0:16 ` Jay Vosburgh
2008-11-02 4:40 ` David Miller
2008-11-04 2:13 ` [PATCH net-next-2.6] bonding, net: Move last_rx update into bonding recv logic Jay Vosburgh
2008-11-04 2:17 ` David Miller
2008-10-10 10:13 ` [tbench regression fixes]: digging out smelly deadmen Mike Galbraith
2008-10-11 13:13 ` Evgeniy Polyakov
2008-10-11 14:39 ` Peter Zijlstra
2008-10-11 18:13 ` Mike Galbraith
2008-10-12 6:02 ` Mike Galbraith
2008-10-12 6:33 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1225011648.27415.4.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=efault@gmx.de \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=s0mbre@tservice.net.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).