public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: rwhron@earthlink.net
Cc: linux-kernel@vger.kernel.org, ltp-list@lists.sourceforge.ent,
	torvalds@transmeta.com
Subject: Re: VM test comparison of 2.4.14-pre5, aa1, and 2.4.13-ac5-fs
Date: Sun, 4 Nov 2001 02:45:41 +0100	[thread overview]
Message-ID: <20011104024541.H1898@athlon.random> (raw)
In-Reply-To: <20011030022640.A225@earthlink.net> <20011030154911.E1340@athlon.random> <20011031004129.A207@earthlink.net>
In-Reply-To: <20011031004129.A207@earthlink.net>; from rwhron@earthlink.net on Wed, Oct 31, 2001 at 12:41:29AM -0500

On Wed, Oct 31, 2001 at 12:41:29AM -0500, rwhron@earthlink.net wrote:
> So I'm thinking about just continuing to use the mtest01 from LTP, 
> knowing that with my test conditions, a variation of a few percent 
> isn't significant.
> 
> Andrea, is that okay with you?

Why don't you use the -b option with the mean size of all the previous
runs that you did with the default -p option? this way you'd avoid
throwing away all the previous results and the new ones would be more
reliable. I'd prefer if you would allocate always the same amount of
memory, the variations are not huge, so I guess it's better to reduce
the userspace noise.

In particular I'm interested if you can see significant performance
variations between pre5aa1 and pre6aa1 and pre7aa2. I'm also testing
here (mainly Linus's 40m kde test to verify interactive response on real
life that unfortunately cannot produce raw numbers) and I didn't had
much time to spend producing numbers since there was also some bug to
fix utill yesterday (should be all fixed in pre7aa2). The recent changes
were mostly in function of the kde mem=40m workload that is pretty well
usable for me in pre7aa2 (xmms never skips one beat while playing mp3
even if mem=40m and browsing the web with konqueror is fluid, mozilla
also is usable but much slower than konqueror with mem=40m because it's
a true memory hog at least when flash starts and of course it shares
less libs with the rest of the desktop).

Andrea

      reply	other threads:[~2001-11-04  1:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-30  7:26 VM test comparison of 2.4.14-pre5, aa1, and 2.4.13-ac5-fs rwhron
2001-10-30  7:34 ` Jens Axboe
2001-10-30 14:49 ` Andrea Arcangeli
2001-10-31  5:41   ` rwhron
2001-11-04  1:45     ` Andrea Arcangeli [this message]

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=20011104024541.H1898@athlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.ent \
    --cc=rwhron@earthlink.net \
    --cc=torvalds@transmeta.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