linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@innominate.de>
To: James Antill <james@and.org>, linux-mm@kvack.org
Subject: Re: Interesting item came up while working on FreeBSD's pageout daemon
Date: Sat, 30 Dec 2000 00:12:07 +0100	[thread overview]
Message-ID: <3A4D1A47.22DA65E8@innominate.de> (raw)
In-Reply-To: <nnzohfc84q.fsf@code.and.org>

James Antill wrote:
> > To estimate the cost of paging io you have to think in terms of the
> > extra work you have to do because you don't have infinite memory.  In
> > other words, you would have had to write those dirty pages anyway - this
> > is an unavoidable cost.  You incur an avoidable cost when you reclaim a
> > page that will be needed again sooner than some other candidate.  If the
> > page was clean the cost is an extra read, if dirty it's a write plus a
> > read.  Alternatively, the dirty page might be written again soon - if
> > it's a partial page write the cost is an extra read and a write, if it's
> > a full page the cost is just a write.  So it costs at most twice as much
> > to guess wrong about a dirty vs clean page.  This difference is
> > significant, but it's not as big as the 1 usec vs 5 msec you suggesed.
> 
>  As I understand it you can't just add the costs of the reads and
> writes as 1 each. So given...
> 
>  Clean = 1r
>  Dirty = 1w + 1r
> 
> ...it's assumed that a 1w is >= than a 1r, but what are the exact
> values ?

By read and write I am talking about the necessary transfers to disk,
not the higher level file IO.  Transfers to and from disk are nearly
equal in cost.

>  It probably gets even more complex as if the dirty page is touched
> between the write and the cleanup then it'll avoid the re-read
> behavior and will appear faster (although it slowed the system down a
> little doing it's write).

Oh yes, it gets more complex.  I'm trying to nail down the main costs by
eliminating the constant factors.

> > If I'm right then making the dirty page go 3 times around the loop
> > should result in worse performance vs 2 times.
> 
>  It's quite possible, but if there were 2 lists and the dirty pages
> were laundered at 33% the rate of the clean pages would that be better
> than 50%?

Eh.  I don't know, I was hoping Matt would try it.

--
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-29 23:12 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
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 [this message]
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=3A4D1A47.22DA65E8@innominate.de \
    --to=phillips@innominate.de \
    --cc=james@and.org \
    --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