linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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/

  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