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/
next prev parent 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