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