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
next prev parent 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