linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: linux-mm@kvack.org
Subject: Re: Interesting item came up while working on FreeBSD's pageout daemon
Date: Thu, 21 Dec 2000 17:47:31 +0100	[thread overview]
Message-ID: <3A423423.F73F1225@innominate.de> (raw)
In-Reply-To: <200012162016.eBGKGW902633@apollo.backplane.com>

Matthew Dillon wrote:
>     My conclusion from this is that I was wrong before when I thought that
>     clean and dirty pages should be treated the same, and I was also wrong
>     trying to give clean pages 'ultimate' priority over dirty pages, but I
>     think I may be right giving dirty pages two go-arounds in the queue
>     before flushing.  Limiting the number of dirty page flushes allowed per
>     pass also works but has unwanted side effects.

Hi, I'm a newcomer to the mm world, but it looks like fun, so I'm
jumping in. :-)

It looks like what you really want are separate lru lists for clean and
dirty.  That way you can tune the rate at which dirty vs clean pages are
moved from active to inactive.

It makes sense that dirty pages should be treated differently from clean
ones because guessing wrong about the inactiveness of a dirty page costs
twice as much as guessing wrong about a clean page (write+read vs just
read).  Does that mean that make dirty pages should hang around on
probation twice as long as clean ones?  Sounds reasonable.

I was going to suggest aging clean and dirty pages at different rates,
then I realized that an inactive_dirty page actually has two chance to
be reactivated, once while it's on inactive_dirty, and again while it's
on inactive_clean, and you get a double-length probation from that.

--
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2000-12-21 16:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-16 20:16 Matthew Dillon
2000-12-21 16:47 ` Daniel Phillips [this message]
2000-12-21 19:42   ` Rik van Riel
2000-12-22  3:20     ` Matthew Dillon
2000-12-28 23:04     ` Daniel Phillips
2000-12-29  6:24       ` Matthew Dillon
2000-12-29 14:19         ` Daniel Phillips
2000-12-29 19:58           ` James Antill
2000-12-29 23:12             ` Daniel Phillips
2000-12-29 23:00         ` Daniel Phillips

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=3A423423.F73F1225@innominate.de \
    --to=phillips@innominate.de \
    --cc=dillon@apollo.backplane.com \
    --cc=linux-mm@kvack.org \
    /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