linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Galbraith <mikeg@wen-online.de>
To: John Stoffel <stoffel@casc.com>
Cc: 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 20:30:32 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.33.0106082013500.672-100000@mikeg.weiden.de> (raw)
In-Reply-To: <15137.3796.287765.4809@gargle.gargle.HOWL>

On Fri, 8 Jun 2001, John Stoffel wrote:

> 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.

Hmm...

Tobias> Could you please explain what is good about this test?  I
Tobias> understand that it will stress the VM, but will it do so in a
Tobias> realistic and relevant way?

I agree, this isn't really a good test case.  I'd rather see what
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
happens when you fire up a gimp session to edit an image which is
*almost* the size of RAM, or even just 50% the size of ram.  Then how
does that affect your other processes that are running at the same
time?

...but anyway, yes it just one test from any number of possibles.

> 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.

What does 'more representative' mean given that the VM must react to
every situation it runs into?

> The kernel compile is an ok test of basic VM handling, but from what

Now we're communicating.  I never said it was more than that ;-)

> 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.

Yes, more people need to test. I don't need to do all of those other
tests (no have right toys), more people need to do repeatable tests.

> 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.

I know I'm only watching basic functionality.  I'm watching basic
functionality with one very consistant test run very consistantly.

	-Mike

--
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/

  parent reply	other threads:[~2001-06-08 18:30 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
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 [this message]
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=Pine.LNX.4.33.0106082013500.672-100000@mikeg.weiden.de \
    --to=mikeg@wen-online.de \
    --cc=chromi@cyberspace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=sean@dev.sportingbet.com \
    --cc=shane@minirl.com \
    --cc=smh1008@cus.cam.ac.uk \
    --cc=stoffel@casc.com \
    --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