From: Rik van Riel <email@example.com>
To: John Stoffel <firstname.lastname@example.org>
Cc: Roger Larsson <email@example.com>,
Daniel Phillips <firstname.lastname@example.org>,
Subject: Re: 2.4.6-pre2, pre3 VM Behavior
Date: Thu, 14 Jun 2001 19:23:58 -0300 (BRST) [thread overview]
Message-ID: <Pine.LNX.email@example.com> (raw)
On Thu, 14 Jun 2001, John Stoffel wrote:
> Rik> There's another issue. If dirty data is written out in small
> Rik> bunches, that means we have to write out the dirty data more
> Rik> often.
> What do you consider a small bunch? 32k? 1Mb? 1% of buffer space?
> I don't see how delaying writes until the buffer is almost full really
> helps us. As the buffer fills, the pressure to do writes should
> increase, so that we tend, over time, to empty the buffer.
> A buffer is just that, not persistent storage.
> And in the case given, we were not seeing slow degradation, we saw
> that the user ran into a wall (or inflection point in the response
> time vs load graph), which was pretty sharp. We need to handle that
> more gracefully.
No doubt on the fact that we need to handle it gracefully,
but as long as we don't have any answers to any of the
tricky questions you're asking above it'll be kind of hard
to come up with a patch ;))
> Rik> This in turn means extra disk seeks, which can horribly interfere
> Rik> with disk reads.
> True, but are we optomizing for reads or for writes here? Shouldn't
> they really be equally weighted for priority? And wouldn't the
> Elevator help handle this to a degree?
We definately need to optimise for reads.
Every time we do a read, we KNOW there's a process waiting
on the data to come in from the disk.
Most of the time we do writes, they'll be asynchronous
delayed IO which is done in the background. The program
which wrote the data has moved on to other things long
> Some areas to think about, at least for me. And maybe it should be
> read and write pressure, not rate?
> - low write rate, and a low read rate.
> - Do seeks dominate our IO latency/throughput?
Seeks always dominate IO latency ;)
If you have a program which needs to get data from some file
on disk, it is beneficial for that program if the disk head
is near the data it wants.
Moving the disk head all the way to the other side of the
disk once a second will not slow the program down too much,
but moving the disk head away 30 times a second "because
there is little disk load" might just slow the program
down by a factor of 2 ...
Ie. if the head is in the same track or in the track next
door, we only have rotational latency to count for (say 3ms),
if we're on the other side of the disk we also have to count
in seek time (say 7ms). Giving the program 30 * 7 = 210 ms
extra IO wait time per second just isn't good ;)
> - low write rate, high read rate.
> - seems like we want to keep writing the buffers, but at a lower
Not at a lower rate, just in larger blocks. Disk transfer
rate is so rediculously high nowadays that seek time seems
the only sensible thing to optimise for.
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
next prev parent reply other threads:[~2001-06-14 22:24 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-13 19:31 2.4.6-pre2, pre3 VM Behavior Tom Sightler
2001-06-13 20:21 ` Rik van Riel
2001-06-14 1:49 ` Tom Sightler
2001-06-14 3:16 ` Rik van Riel
2001-06-14 7:59 ` Laramie Leavitt
2001-06-14 9:24 ` Helge Hafting
2001-06-14 17:38 ` Mark Hahn
2001-06-15 8:27 ` Helge Hafting
2001-06-14 8:47 ` Daniel Phillips
2001-06-14 20:23 ` Roger Larsson
2001-06-15 6:04 ` Mike Galbraith
2001-06-14 20:39 ` John Stoffel
2001-06-14 20:51 ` Rik van Riel
2001-06-14 21:33 ` John Stoffel
2001-06-14 22:23 ` Rik van Riel [this message]
2001-06-15 15:23 ` spindown [was Re: 2.4.6-pre2, pre3 VM Behavior] Pavel Machek
2001-06-16 20:50 ` Daniel Phillips
2001-06-16 21:06 ` Rik van Riel
2001-06-16 21:25 ` Rik van Riel
2001-06-16 21:44 ` Daniel Phillips
2001-06-16 21:54 ` Rik van Riel
2001-06-17 10:28 ` Daniel Phillips
2001-06-17 10:05 ` Mike Galbraith
2001-06-17 12:49 ` (lkml)Re: " thunder7
2001-06-17 16:40 ` Mike Galbraith
2001-06-18 14:22 ` Daniel Phillips
2001-06-19 4:35 ` Mike Galbraith
2001-06-20 1:50 ` [RFC] Early flush (was: spindown) Daniel Phillips
2001-06-20 20:58 ` Tom Sightler
2001-06-20 22:09 ` Daniel Phillips
2001-06-24 3:20 ` Anuradha Ratnaweera
2001-06-24 11:14 ` Daniel Phillips
2001-06-24 15:06 ` Rik van Riel
2001-06-24 16:21 ` Daniel Phillips
2001-06-20 4:39 ` Richard Gooch
2001-06-20 14:29 ` Daniel Phillips
2001-06-20 16:12 ` Richard Gooch
2001-06-22 23:25 ` Daniel Kobras
2001-06-23 5:10 ` Daniel Phillips
2001-06-25 11:33 ` Pavel Machek
2001-06-25 11:31 ` Pavel Machek
2001-06-18 20:21 ` spindown Simon Huggins
2001-06-19 10:46 ` spindown Pavel Machek
2001-06-20 16:52 ` spindown Daniel Phillips
2001-06-20 17:32 ` spindown Rik van Riel
2001-06-20 18:00 ` spindown Daniel Phillips
2001-06-21 16:07 ` spindown Jamie Lokier
2001-06-22 22:09 ` spindown Daniel Kobras
2001-06-28 0:27 ` spindown Troy Benjegerdes
2001-06-14 15:10 ` 2.4.6-pre2, pre3 VM Behavior John Stoffel
2001-06-14 18:25 ` Daniel Phillips
2001-06-14 8:30 ` Mike Galbraith
[not found] <Pine.LNX.firstname.lastname@example.org>
2001-06-14 2:08 ` Tom Sightler
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).