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.net
Subject: Re: VM test on 2.4.13-pre3aa1 (compared to 2.4.12-aa1 and 2.4.13-pre2aa1)
Date: Wed, 17 Oct 2001 02:12:42 +0200	[thread overview]
Message-ID: <20011017021242.S2380@athlon.random> (raw)
In-Reply-To: <20011016081639.A209@earthlink.net>
In-Reply-To: <20011016081639.A209@earthlink.net>; from rwhron@earthlink.net on Tue, Oct 16, 2001 at 08:16:39AM -0400

On Tue, Oct 16, 2001 at 08:16:39AM -0400, rwhron@earthlink.net wrote:
> 
> Summary:
> 
> Wall clock time for this test has dropped dramatically (which
> is good) over the last 3 Andrea Arcangeli patched kernels.

:) I worked the last two days to make it faster under swap, it's nice to
see that your tests also confirm that.  I'm only scared it swaps too
much when swap is not used but if this sorts out to be the case it will
be very easy to fix. And a very minor bit of very seldom background
pagetable scanning shouldn't hurt anyways. So far on my desktop it seems
not to swap too much.

> mp3blaster sounds less pleasant though.

A (very) optimistic theory could be that the increase of the swap
throughput is decreasing the bandiwth available to read the mp3 8). Do
you swap on the same physical disk where you keep the mp3? But it maybe
that I'm blocking too easily waiting for I/O completion instead, or that
the mp3blast routines needed for the playback are been swapped out,
dunno with only this info. You can rule out the "mp3blast is been
swapped out" by running mp3blast after an mlockall. And you can avoid
the disk bandwith problems by putting the mp3 in a separate disk.

So far I received very good feedback about 2.4.13pre3aa1 [also Luigi's
and Mario's problems gone away completly] (I'm also happy myself on my
machine). It may need further tuning but I'd hope it's only a matter of
changing some line of code.

>  3  3  0  47424   3788   1172   1412 860 40228   892 40236  789   819  12  23  66
>  0  5  1  90244   1656   1184   1416 1032 39568  1076 39572  653   425   6   5  89

those swapins could be due mp3blast that is getting swapped out
continously while it sleeps.  Not easy for the vm to understand it has
to stay in cache and it makes sense it gets swapped out faster, the
faster the swap rate is. Could you also make sure to run mp3blast with
-20 priority and the swap-hog at +19 priority just in case?

thanks for feedback!

Andrea

  reply	other threads:[~2001-10-17  0:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-16 12:16 VM test on 2.4.13-pre3aa1 (compared to 2.4.12-aa1 and 2.4.13-pre2aa1) rwhron
2001-10-17  0:12 ` Andrea Arcangeli [this message]
2001-10-17  1:32   ` Beau Kuiper
2001-10-17  2:09     ` Andrea Arcangeli
2001-10-18 19:36       ` bill davidsen
2001-10-18 23:27         ` Andrea Arcangeli
2001-10-17  2:31   ` Andrea Arcangeli
2001-10-17  4:48     ` rwhron
2001-10-17 16:27       ` Linus Torvalds
2001-10-17 15:19         ` Marcelo Tosatti
2001-10-18 19:45       ` Bill Davidsen
2001-10-17  3:59   ` rwhron

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=20011017021242.S2380@athlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=rwhron@earthlink.net \
    /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