linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Stoffel <stoffel@casc.com>
To: Mike Galbraith <mikeg@wen-online.de>
Cc: John Stoffel <stoffel@casc.com>,
	Tobias Ringstrom <tori@unhappy.mine.nu>,
	Jonathan Morton <chromi@cyberspace.org>,
	Shane Nay <shane@minirl.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	"Dr S.M. Huen" <smh1008@cus.cam.ac.uk>,
	Sean Hunter <sean@dev.sportingbet.com>,
	Xavier Bestel <xavier.bestel@free.fr>,
	lkml <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: VM Report was:Re: Break 2.4 VM in five easy steps
Date: Fri, 8 Jun 2001 13:43:48 -0400	[thread overview]
Message-ID: <15137.3796.287765.4809@gargle.gargle.HOWL> (raw)
In-Reply-To: <Pine.LNX.4.33.0106081853400.418-100000@mikeg.weiden.de>

Mike> OK, riddle me this.  If this test is a crummy test, just how is
Mike> it that I was able to warn Rik in advance that when 2.4.5 was
Mike> released, he should expect complaints?  How did I _know_ that?
Mike> The answer is that I fiddle with Rik's code a lot, and I test
Mike> with this test because it tells me a lot.  It may not tell you
Mike> anything, but it does me.

I never said it was a crummy test, please do not read more into my
words than was written.  What I was trying to get across is that just
one test (such as a compile of the kernel) isn't perfect at showing
where the problems are with the VM sub-system.

Jonathan Morton has been using another large compile to also test the
sub-system, and it includes a compile which puts a large, single
process pressure on the VM.  I consider this to be a more
representative test of how the VM deals with pressure.  

The kernel compile is an ok test of basic VM handling, but from what
I've been hearing on linux-kernel and linux-mm is that the VM goes to
crap when you have a mix of stuff running, and one (or more) processes
starts up or grows much larger and starts impacting the system
performance.

I'm also not knocking your contributions to this discussion, so stop
being so touchy.  I was trying to contribute and say (albeit poorly)
that a *mix* of tests is needed to test the VM.

More importantly, a *repeatable* set of tests is what is needed to
test the VM and get consistent results from run to run, so you can see
how your changes are impacting performance.  The kernel compile
doesn't really have any one process grow to a large fraction of
memory, so dropping in a compile which *does* is a good thing.

John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
	 stoffel@lucent.com - http://www.lucent.com - 978-952-7548

--
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-06-08 17:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.21.0106071722450.1156-100000@freak.distro.conectiva>
2001-06-07 23:29 ` Shane Nay
2001-06-08  1:18   ` Jonathan Morton
2001-06-08 12:50     ` Mike Galbraith
2001-06-08 14:19       ` Tobias Ringstrom
2001-06-08 15:51         ` John Stoffel
2001-06-08 17:01           ` Mike Galbraith
2001-06-08 17:43             ` John Stoffel [this message]
2001-06-08 17:35               ` Marcelo Tosatti
2001-06-08 20:58                 ` John Stoffel
2001-06-08 20:04                   ` Marcelo Tosatti
2001-06-08 23:44                     ` Jonathan Morton
2001-06-09  2:36                       ` Andrew Morton
2001-06-09  3:43                       ` Mike Galbraith
2001-06-09  4:05                         ` Jonathan Morton
2001-06-09  5:09                           ` Mike Galbraith
2001-06-09  5:07                 ` Mike Galbraith
2001-06-08 18:30               ` Mike Galbraith
2001-06-09 12:31                 ` Zlatko Calusic
2001-06-09  3:34             ` Rik van Riel
2001-06-08 16:51         ` Mike Galbraith
2001-06-08 19:09           ` Tobias Ringstrom
2001-06-09  4:36             ` 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=15137.3796.287765.4809@gargle.gargle.HOWL \
    --to=stoffel@casc.com \
    --cc=chromi@cyberspace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=mikeg@wen-online.de \
    --cc=sean@dev.sportingbet.com \
    --cc=shane@minirl.com \
    --cc=smh1008@cus.cam.ac.uk \
    --cc=tori@unhappy.mine.nu \
    --cc=xavier.bestel@free.fr \
    /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