linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: James Antill <james@and.org>
To: Daniel Phillips <phillips@innominate.de>
Cc: linux-mm@kvack.org
Subject: Re: Interesting item came up while working on FreeBSD's pageout daemon
Date: 29 Dec 2000 14:58:13 -0500	[thread overview]
Message-ID: <nnzohfc84q.fsf@code.and.org> (raw)
In-Reply-To: Daniel Phillips's message of "Fri, 29 Dec 2000 15:19:50 +0100"

> Matthew Dillon wrote:
> >     The effect of this (and, more importantly, limiting the number of dirty
> >     pages one is willing to launder in the first pageout pass) is rather
> >     significant due to the big difference in cost in dealing with clean
> >     pages verses dirty pages.
> > 
> >     'cleaning' a clean page means simply throwing it away, which costs maybe
> >     a microsecond of cpu time and no I/O.  'cleaning' a dirty page requires
> >     flushing it to its backing store prior to throwing it away, which costs
> >     a significant bit of cpu and at least one write I/O.  One write I/O
> >     may not seem like a lot, but if the disk is already loaded down and the
> >     write I/O has to seek we are talking at least 5 milliseconds of disk
> >     time eaten by the operation.  Multiply this by the number of dirty pages
> >     being flushed and it can cost a huge and very noticeable portion of
> >     your disk bandwidth, verses zip for throwing away a clean page.
> 
> 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 ?
 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).

> 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%?

-- 
# James Antill -- james@and.org
:0:
* ^From: .*james@and.org
/dev/null
--
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 19:58 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 [this message]
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=nnzohfc84q.fsf@code.and.org \
    --to=james@and.org \
    --cc=linux-mm@kvack.org \
    --cc=phillips@innominate.de \
    /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