From: Daniel Phillips <phillips@bonn-fries.net>
To: John Stoffel <stoffel@casc.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
Tom Sightler <ttsig@tuxyturvy.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.4.6-pre2, pre3 VM Behavior
Date: Thu, 14 Jun 2001 20:25:09 +0200 [thread overview]
Message-ID: <01061420250909.00879@starship> (raw)
In-Reply-To: <Pine.LNX.4.21.0106140013000.14934-100000@imladris.rielhome.conectiva> <01061410474103.00879@starship> <15144.54236.903016.433760@gargle.gargle.HOWL>
In-Reply-To: <15144.54236.903016.433760@gargle.gargle.HOWL>
On Thursday 14 June 2001 17:10, John Stoffel wrote:
> >> 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.
>
> Daniel> This still doesn't make sense if the disk bandwidth isn't
> Daniel> being used.
>
> And can't you tell that a certain percentage of buffers are owned by a
> single file/process? It would seem that a simple metric of
>
> if ##% of the buffer/cache is used by 1 process/file, start
> writing the file out to disk, even if there is no pressure.
>
> might do the trick to handle this case.
Buffers and file pages are owned by the vfs, not processes pre se, so it
makes accounting harder. In this case you don't care: it's a file, so in the
absence of memory pressure and with disk bandwidth available it's better to
get the data onto disk sooner rather than later. (This glosses over the
question of mmap's, by the way.) It's pretty hard to see why there is any
benefit at all in delaying, but it's clear there's a benefit in terms of data
safety and a further benefit in terms of doing what the user expects.
> >> 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 ?
>
> Daniel> For file-backed pages what we want is pretty simple: when 1)
> Daniel> disk bandwidth is less than xx% used 2) memory pressure is
> Daniel> moderate, just submit whatever's dirty. As pressure increases
> Daniel> and bandwidth gets loaded up (including read traffic) leave
> Daniel> things on the inactive list longer to allow more chances for
> Daniel> combining and better clustering decisions.
>
> Would it also be good to say that pressure should increase as the
> buffer.free percentage goes down?
Maybe - right now getblk waits until it runs completely out of buffers of a
given size before trying to allocate more, which means that sometimes an io
will be delayed by the time it takes to complete a page_launder cycle. Two
reasons why it may not be worth doing anything about this: 1) we will move
most of the buffer users into the page cache in due course 2) the frequency
of this kind of io delay is *probably* pretty low.
> It won't stop you from filling the
> buffer, but it should at least start pushing out pages to disk
> earlier.
--
Daniel
next prev parent reply other threads:[~2001-06-14 18:22 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
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 [this message]
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=01061420250909.00879@starship \
--to=phillips@bonn-fries.net \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=stoffel@casc.com \
--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).