From: Stephan von Krawczynski <skraw@ithnet.com>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: riel@conectiva.com.br, jaharkes@cs.cmu.edu,
marcelo@conectiva.com.br, linux-kernel@vger.kernel.org
Subject: Re: page_launder() on 2.4.9/10 issue
Date: Thu, 6 Sep 2001 15:10:15 +0200 [thread overview]
Message-ID: <20010906151015.69d2afb2.skraw@ithnet.com> (raw)
In-Reply-To: <20010906122459Z16031-32383+3771@humbolt.nl.linux.org>
In-Reply-To: <Pine.LNX.4.33L.0109060851020.31200-100000@imladris.rielhome.conectiva> <20010906122459Z16031-32383+3771@humbolt.nl.linux.org>
On Thu, 6 Sep 2001 14:31:32 +0200 Daniel Phillips <phillips@bonn-fries.net>
wrote:
> On September 6, 2001 01:52 pm, Rik van Riel wrote:
> > On Tue, 4 Sep 2001, Jan Harkes wrote:
> >
> > > To get back on the thread I jumped into, I totally agree with Linus
> > > that writeout should be as soon as possible.
> >
> > Nice way to destroy read performance.
>
> Blindly delaying all the writes in the name of better read performance isn't
> the right idea either. Perhaps we should have a good think about some
> sensible mechanism for balancing reads against writes.
I guess I have the real-world proof for that:
Yesterday I mastered a CD (around 700 MB) and burned it, I left the equipment
to get some food and sleep (sometimes needed :-). During this time the machine
acts as nfs-server and gets about 3 GB of data written to it. Coming back today
I recognise that deleting the CD image made yesterday frees up about 500 MB of
physical mem (free mem was very low before). It was obviously held 24 hours for
no reason, and _not_ (as one would expect) exchanged against the nfs-data. This
means the caches were full with _old_ data and explains why nfs performance has
remarkably dropped since 2.2. There is too few mem around to get good
performance (no matter if read or write). Obviously aging did not work at all,
there was not a single hit on these (CD image) pages during 24 hours, compared
to lots on the nfs-data. Even if the nfs-data would only have one single hit,
the old CD image should have been removed, because it is inactive and _older_.
> > As DaveM noted so
> > nicely in his reverse mapping patch (at the end of the
> > 2.3 series), dirty pages get moved to the laundry list
> > and the washing machine will deal with them when we have
> > a full load.
> >
> > Lets face it, spinning the washing machine is expensive
> > and running less than a full load makes things inefficient ;)
I guess this is what people writing w*ndows screen blankers thought, too ;-)
Sorry for this comment, couldn't resist :-)
Stephan
next prev parent reply other threads:[~2001-09-06 13:10 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-28 3:36 page_launder() on 2.4.9/10 issue Marcelo Tosatti
2001-08-28 18:07 ` Daniel Phillips
2001-08-28 18:17 ` Linus Torvalds
2001-08-30 1:36 ` Daniel Phillips
2001-09-03 14:57 ` Marcelo Tosatti
2001-09-04 15:26 ` Jan Harkes
2001-09-04 15:24 ` Marcelo Tosatti
2001-09-04 17:14 ` Jan Harkes
2001-09-04 15:53 ` Marcelo Tosatti
2001-09-04 19:33 ` Daniel Phillips
2001-09-06 11:52 ` Rik van Riel
2001-09-06 12:31 ` Daniel Phillips
2001-09-06 12:32 ` Rik van Riel
2001-09-06 12:53 ` Daniel Phillips
2001-09-06 13:03 ` Rik van Riel
2001-09-06 13:18 ` Kurt Garloff
2001-09-06 13:23 ` Rik van Riel
2001-09-06 13:28 ` Alan Cox
2001-09-06 13:29 ` Rik van Riel
2001-09-06 16:45 ` Daniel Phillips
2001-09-06 16:57 ` Rik van Riel
2001-09-06 17:22 ` Daniel Phillips
2001-09-06 19:25 ` Rik van Riel
2001-09-06 19:45 ` Daniel Phillips
2001-09-06 19:52 ` Rik van Riel
2001-09-07 0:32 ` Kurt Garloff
2001-09-06 19:53 ` Mike Fedyk
2001-09-06 17:35 ` Mike Fedyk
2001-09-06 13:10 ` Stephan von Krawczynski [this message]
2001-09-06 13:23 ` Alex Bligh - linux-kernel
2001-09-06 13:42 ` Stephan von Krawczynski
2001-09-06 14:01 ` Alex Bligh - linux-kernel
2001-09-06 14:39 ` Stephan von Krawczynski
2001-09-06 15:02 ` Alex Bligh - linux-kernel
2001-09-06 15:07 ` Rik van Riel
[not found] ` <Pine.LNX.4.33L.0109061206020.31200-100000@imladris.rielhome.con ectiva>
2001-09-06 15:16 ` Alex Bligh - linux-kernel
2001-09-06 15:10 ` Stephan von Krawczynski
2001-09-06 15:18 ` Alex Bligh - linux-kernel
2001-09-06 17:34 ` Daniel Phillips
2001-09-06 17:32 ` Alex Bligh - linux-kernel
2001-09-06 13:54 ` M. Edward Borasky
2001-09-06 14:39 ` Alan Cox
2001-09-06 16:20 ` Victor Yodaiken
2001-09-06 17:33 ` Daniel Phillips
2001-09-06 17:51 ` Daniel Phillips
2001-09-06 21:01 ` [RFC] Defragmentation proposal: preventative maintenance and cleanup [LONG] Alex Bligh - linux-kernel
2001-09-07 6:35 ` Daniel Phillips
2001-09-07 8:58 ` Alex Bligh - linux-kernel
2001-09-07 9:15 ` Alex Bligh - linux-kernel
2001-09-07 9:28 ` Alex Bligh - linux-kernel
2001-09-07 21:38 ` Daniel Phillips
2001-09-07 21:56 ` Daniel Phillips
2001-09-07 12:30 ` page_launder() on 2.4.9/10 issue Stephan von Krawczynski
2001-09-04 16:27 ` Rik van Riel
2001-09-04 17:13 ` Jan Harkes
2001-09-04 15:56 ` Marcelo Tosatti
2001-09-04 17:54 ` Jan Harkes
2001-09-04 16:37 ` Marcelo Tosatti
2001-09-04 18:49 ` Alan Cox
2001-09-04 19:39 ` Jan Harkes
2001-09-04 20:25 ` Alan Cox
2001-09-06 11:23 ` Rik van Riel
2001-09-04 19:54 ` Andrea Arcangeli
2001-09-04 18:36 ` Marcelo Tosatti
2001-09-04 20:10 ` Daniel Phillips
2001-09-04 22:04 ` Andrea Arcangeli
2001-09-05 2:41 ` Daniel Phillips
2001-09-06 11:18 ` Rik van Riel
2001-09-04 17:35 ` Daniel Phillips
2001-09-04 20:43 ` Jan Harkes
2001-09-06 11:21 ` Rik van Riel
[not found] <20010828180108Z16193-32383+2058@humbolt.nl.linux.org.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.33.0108281110540.8754-100000@penguin.transmeta.com.suse.lists.linux.kernel>
2001-08-28 19:14 ` Andi Kleen
2001-08-28 20:01 ` David S. Miller
2001-08-28 20:49 ` Linus Torvalds
2001-08-28 20:56 ` David S. Miller
2001-08-29 13:48 ` Rik van Riel
2001-08-29 13:49 ` Linus Torvalds
2001-08-29 14:38 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2001-09-27 23:14 Samium Gromoff
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=20010906151015.69d2afb2.skraw@ithnet.com \
--to=skraw@ithnet.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=phillips@bonn-fries.net \
--cc=riel@conectiva.com.br \
/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