linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Rik van Riel <riel@conectiva.com.br>, Tom Sightler <ttsig@tuxyturvy.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.6-pre2, pre3 VM Behavior
Date: Thu, 14 Jun 2001 10:47:41 +0200	[thread overview]
Message-ID: <01061410474103.00879@starship> (raw)
In-Reply-To: <Pine.LNX.4.21.0106140013000.14934-100000@imladris.rielhome.conectiva>
In-Reply-To: <Pine.LNX.4.21.0106140013000.14934-100000@imladris.rielhome.conectiva>

On Thursday 14 June 2001 05:16, Rik van Riel wrote:
> On Wed, 13 Jun 2001, Tom Sightler wrote:
> > Quoting Rik van Riel <riel@conectiva.com.br>:
> > > After the initial burst, the system should stabilise,
> > > starting the writeout of pages before we run low on
> > > memory. How to handle the initial burst is something
> > > I haven't figured out yet ... ;)
> >
> > Well, at least I know that this is expected with the VM, although I do
> > still think this is bad behavior.  If my disk is idle why would I wait
> > until I have greater than 100MB of data to write before I finally
> > start actually moving some data to disk?
>
> The file _could_ be a temporary file, which gets removed
> before we'd get around to writing it to disk. Sure, the
> chances of this happening with a single file are close to
> zero, but having 100MB from 200 different temp files on a
> shell server isn't unreasonable to expect.

This still doesn't make sense if the disk bandwidth isn't being used.

> Maybe we should just see if anything in the first few MB
> of inactive pages was freeable, limiting the first scan to
> something like 1 or maybe even 5 MB maximum (freepages.min?
> freepages.high?) and flushing as soon as we find more unfreeable
> pages than that ?

There are two cases, file-backed and swap-backed pages.

For file-backed pages what we want is pretty simple: when 1) disk bandwidth 
is less than xx% used 2) memory pressure is moderate, just submit whatever's 
dirty.  As pressure increases and bandwidth gets loaded up (including read 
traffic) leave things on the inactive list longer to allow more chances for 
combining and better clustering decisions.

There is no such obvious answer for swap-backed pages; the main difference is 
what should happen under low-to-moderate pressure.  On a server we probably 
want to pre-write as many inactive/dirty pages to swap as possible in order 
to respond better to surges, even when pressure is low.  We don't want this 
behaviour on a laptop, otherwise the disk would never spin down.  There's a 
configuration parameter in there somewhere.

--
Daniel

  parent reply	other threads:[~2001-06-14  8:45 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-13 19:31 2.4.6-pre2, pre3 VM Behavior Tom Sightler
2001-06-13 20:21 ` Rik van Riel
2001-06-14  1:49   ` Tom Sightler
2001-06-14  3:16     ` Rik van Riel
2001-06-14  7:59       ` Laramie Leavitt
2001-06-14  9:24         ` Helge Hafting
2001-06-14 17:38           ` Mark Hahn
2001-06-15  8:27             ` Helge Hafting
2001-06-14  8:47       ` Daniel Phillips [this message]
2001-06-14 20:23         ` Roger Larsson
2001-06-15  6:04           ` Mike Galbraith
2001-06-14 20:39         ` John Stoffel
2001-06-14 20:51           ` Rik van Riel
2001-06-14 21:33           ` John Stoffel
2001-06-14 22:23             ` Rik van Riel
2001-06-15 15:23           ` spindown [was Re: 2.4.6-pre2, pre3 VM Behavior] Pavel Machek
2001-06-16 20:50             ` Daniel Phillips
2001-06-16 21:06               ` Rik van Riel
2001-06-16 21:25                 ` Rik van Riel
2001-06-16 21:44                 ` Daniel Phillips
2001-06-16 21:54                   ` Rik van Riel
2001-06-17 10:28                     ` Daniel Phillips
2001-06-17 10:05                   ` Mike Galbraith
2001-06-17 12:49                     ` (lkml)Re: " thunder7
2001-06-17 16:40                       ` Mike Galbraith
2001-06-18 14:22                     ` Daniel Phillips
2001-06-19  4:35                       ` Mike Galbraith
2001-06-20  1:50                       ` [RFC] Early flush (was: spindown) Daniel Phillips
2001-06-20 20:58                         ` Tom Sightler
2001-06-20 22:09                           ` Daniel Phillips
2001-06-24  3:20                           ` Anuradha Ratnaweera
2001-06-24 11:14                             ` Daniel Phillips
2001-06-24 15:06                             ` Rik van Riel
2001-06-24 16:21                               ` Daniel Phillips
2001-06-20  4:39                       ` Richard Gooch
2001-06-20 14:29                         ` Daniel Phillips
2001-06-20 16:12                         ` Richard Gooch
2001-06-22 23:25                           ` Daniel Kobras
2001-06-23  5:10                             ` Daniel Phillips
2001-06-25 11:33                               ` Pavel Machek
2001-06-25 11:31                           ` Pavel Machek
2001-06-18 20:21             ` spindown Simon Huggins
2001-06-19 10:46               ` spindown Pavel Machek
2001-06-20 16:52                 ` spindown Daniel Phillips
2001-06-20 17:32                   ` spindown Rik van Riel
2001-06-20 18:00                     ` spindown Daniel Phillips
2001-06-21 16:07                 ` spindown Jamie Lokier
2001-06-22 22:09                   ` spindown Daniel Kobras
2001-06-28  0:27                   ` spindown Troy Benjegerdes
2001-06-14 15:10       ` 2.4.6-pre2, pre3 VM Behavior John Stoffel
2001-06-14 18:25         ` Daniel Phillips
2001-06-14  8:30   ` Mike Galbraith
     [not found] <Pine.LNX.4.10.10106140024230.980-100000@coffee.psychology.mcmaster.ca>
2001-06-14  2:08 ` Tom Sightler

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=01061410474103.00879@starship \
    --to=phillips@bonn-fries.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    --cc=ttsig@tuxyturvy.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;
as well as URLs for NNTP newsgroup(s).