From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Cc: Linux Kernel <linux-kernel@vger.rutgers.edu>,
Linux MM <linux-mm@kvack.org>
Subject: Re: 2.1.131 first impressions
Date: Mon, 7 Dec 1998 13:02:04 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.3.96.981207125304.23360E-100000@mirkwood.dummy.home> (raw)
In-Reply-To: <19981207005145.A832@tantalophile.demon.co.uk>
On Mon, 7 Dec 1998, Jamie Lokier wrote:
> I've just switched from 2.1.129 to 2.1.131 + Rik's "fastest VM system"
> patch, and I have to say, nice!
>
> Disk activity
> =============
>
> Something's changed. Can't say whether it's the main tree changes or
> Rik's mm changes (I haven't tried plain 2.1.131).
Both. Stephen's changes to shrink_mmap() really have a huge
influence on performance.
> I'm not using any swap either (well, 16k on a 64MB system). It feels
> faster somehow anyway.
The not-using-any-swap part comes both from Stephen's improvement
and my change to vmscan.c; we now quit a swap_out() loop earlier
and we do (over?-)agressive pruning of the page and buffer caches.
> Well, apart from Squid which still spends a few minutes grinding
> away at the disk when it starts. I would like to find a way to fix
> this, it's probably the most thrashy thing my disk has to handle and
> it does slow down everything else for a while quite significantly.
This could be a side effect of a too agressive pruning of the
caches. We should fix this.
> Netscape still hits the disk very hard when it starts, and takes what
> seems like just as long. Netscape is pretty quick to start the second
> time though (about 3 seconds), so it's definitely a paging thing. Is
> there anything which could be done with paging
> read-ahead/read-behind/read-cleverer to make Netscape not thrash the
> disk when it starts?
No, not really. When Netscape starts it is not in cache yet :)
I agree that we should do better readbehind though. I am
currently designing a nice algorithm for deciding whether
to do read-ahead, read-behind, a bit of both or a lot of
both. It is mainly focused at swap I/O though...
File I/O might be better served with a slightly different
algorithm, so we need a volunteer for that... If you are
that volunteer: linux-mm@kvack.org is the list to be.
regards,
Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
parent reply other threads:[~1998-12-07 13:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <19981207005145.A832@tantalophile.demon.co.uk>]
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.3.96.981207125304.23360E-100000@mirkwood.dummy.home \
--to=h.h.vanriel@phys.uu.nl \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=lkd@tantalophile.demon.co.uk \
/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