From: Daniel Phillips <phillips@bonn-fries.net>
To: Roger Larsson <roger.larsson@skelleftea.mail.telia.com>,
linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Subject: Re: 2.4.8-pre1 and dbench -20% throughput
Date: Sat, 28 Jul 2001 03:11:16 +0200 [thread overview]
Message-ID: <0107280311160X.00285@starship> (raw)
In-Reply-To: <200107272347.f6RNlTs15460@maild.telia.com>
On Saturday 28 July 2001 01:43, Roger Larsson wrote:
> Hi again,
>
> It might be variations in dbench - but I am not sure since I run
> the same script each time.
>
> (When I made a testrun in a terminal window - with X running, but not
> doing anything activly, I got
> [some '.' deleted]
> .............++++++++++++++++++++++++++++++++************************
>******** Throughput 15.8859 MB/sec (NB=19.8573 MB/sec 158.859
> MBit/sec) 14.74user 22.92system 4:26.91elapsed 14%CPU
> (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs
> (912major+1430minor)pagefaults 0swaps
>
> I have never seen anyting like this - all '+' together!
>
> I logged off and tried again - got more normal values 32 MB/s
> and '+' were spread out.
>
> More testing needed...
Truly wild, truly crazy. OK, this is getting interesting. I'll go
read the dbench source now, I really want to understand how the IO and
thread sheduling are interrelated. I'm not even going to try to
advance a theory just yet ;-)
I'd mentioned that dbench seems to run fastest when threads run and
complete all at different times instead of all together. It's easy to
see why this might be so: if the sum of all working sets is bigger than
memory then the system will thrash and do its work much more slowly.
If the threads *can* all run independently (which I think is true of
dbench because it simulates SMB accesses from a number of unrelated
sources) then the optimal strategy is to suspend enough processes so
that all the working sets do fit in memory. Linux has no mechanism for
detecting or responding to such situations (whereas FreeBSD - our
arch-rival in the mm sweepstakes - does) so we sometimes see what are
essentially random variations in scheduling causing very measurable
differences in throughput. (The "butterfly effect" where the beating
wings of a butterfly in Alberta set in motion a chain of events that
culminates with a hurricane in Florida.)
I am not saying this is the effect we're seeing here (the working set
effect, not the butterfly:-) but it is something to keep in mind when
investigating this. There is such a thing as being too fair, and maybe
that's what we're running into here.
--
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2001-07-28 1:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200107272112.f6RLC3d28206@maila.telia.com>
[not found] ` <0107280034050V.00285@starship>
2001-07-27 23:43 ` Roger Larsson
2001-07-28 1:11 ` Daniel Phillips [this message]
2001-07-28 3:18 ` Daniel Phillips
2001-07-28 13:40 ` Marcelo Tosatti
2001-07-28 20:13 ` Daniel Phillips
2001-07-28 20:26 ` Linus Torvalds
2001-07-29 14:10 ` Daniel Phillips
2001-07-29 14:48 ` Rik van Riel
2001-07-29 15:34 ` Daniel Phillips
2001-07-29 15:31 ` Mike Galbraith
2001-07-29 16:05 ` Linus Torvalds
2001-07-29 20:19 ` Hugh Dickins
2001-07-29 20:25 ` Rik van Riel
2001-07-29 20:44 ` Hugh Dickins
2001-07-29 21:20 ` Daniel Phillips
2001-07-29 21:51 ` Hugh Dickins
2001-07-29 23:23 ` Rik van Riel
2001-07-31 7:30 ` Kai Henningsen
2001-07-31 14:13 ` Daniel Phillips
2001-07-31 17:37 ` Jonathan Morton
2001-07-29 1:41 ` Andrew Morton
2001-07-29 14:39 ` Daniel Phillips
2001-07-30 3:19 ` Theodore Tso
2001-07-30 15:17 ` Randy.Dunlap
2001-07-30 16:41 ` Theodore Tso
2001-07-30 17:52 ` Mike Galbraith
2001-07-30 19:39 ` Zlatko Calusic
2001-07-29 17:48 ` Steven Cole
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=0107280311160X.00285@starship \
--to=phillips@bonn-fries.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=roger.larsson@skelleftea.mail.telia.com \
/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