From: Andrew Morton <akpm@zip.com.au>
To: war war <war@starband.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.4.16 & Heavy I/O
Date: Thu, 29 Nov 2001 10:01:31 -0800 [thread overview]
Message-ID: <3C0677FB.88AE4196@zip.com.au> (raw)
In-Reply-To: <B7F1F9B7DE30EDF47ADB4F8F44CAC84B@war.starband.net>
war war wrote:
>
> Issue:
>
Here I go again.
> Is it possible to set the disk cache size to a higher value to avoid
> temporary freezing while untarring large files? Memory is not an
> issue, I have plenty of it. The disk drive is a good drive, does
> 29.2MB/s sustained in single user mode, 25MB/s when I have a lot of
> processes open. Here is what I think is going on. Sometimes, when I
> untar things, or do things that consume a lot of disk space rapidly,
> they do it VERY quickly, and then the disk rumbles on for 5-20
> seconds after it is done. What accounts for this?
What is unclear from your report is how this behaviour differs
from what linux has _always_ done. The kernel implements
delayed writeback. Write data isn't fully flushed until up
to thirty seconds after it was written.
So... what filesystem do you use, and how do you think current
behaviour differs from earlier kernels?
I can tell you a few things: there are basically three ways in
which write() data gets IO started on it:
1: Directly, when someone does a write(), if the amount of pending write
data is too high.
2: From within the VM code, when it detects that the ratios of
free-to-dirty-to-clean memory are getting out of whack.
3: Within the kupdate daemon, when it is detected that the
data is thirty seconds old.
In current kernels, with your sort of workload, it appears that
all IO is being initiated by method 2. It also appears that
method 2 simply doesn't do it very well - I've earlier observed
that simply writing a 650 megabyte chunk of /dev/zero into a
file runs 30% faster on ext3 than on ext2. Because ext2 uses
method 2, and it should be using method 1, and ext3 uses, err,
method 4.
Are you inclined to try a patch, and let us know if the result
is better? (coz if you don't nothing will happen!)
http://www.zip.com.au/~akpm/linux/2.4/2.4.17-pre1/vm-fixes.patch
It causes writeout to be initiated via the dirty buffer LRU, not the
inactive list.
Also,
http://www.zip.com.au/~akpm/linux/2.4/2.4.17-pre1/elevator.patch
It lets you read data from the disk when writes are happening.
-
next prev parent reply other threads:[~2001-11-29 18:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-29 15:46 Kernel 2.4.16 & Heavy I/O war war
2001-11-29 15:43 ` Blue Lang
2001-11-29 18:01 ` Andrew Morton [this message]
2001-11-29 21:42 ` Martin Josefsson
2001-11-30 13:59 ` Helge Hafting
2001-12-05 19:57 ` Pablo Borges
2001-12-05 20:07 ` Roy Sigurd Karlsbakk
2001-12-06 18:06 ` Pablo Borges
2001-12-06 18:10 ` Roy Sigurd Karlsbakk
2001-12-06 18:28 ` Pablo Borges
2001-12-06 18:38 ` Rik van Riel
2001-12-06 19:36 ` Mike Galbraith
2001-12-06 19:56 ` Rik van Riel
2001-12-06 22:50 ` Alan Cox
2001-12-07 5:37 ` Mike Galbraith
2001-12-07 8:43 ` Alan Cox
2001-12-07 21:53 ` Mike Galbraith
2001-12-07 22:02 ` Rik van Riel
2001-12-07 13:46 ` Stephan von Krawczynski
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=3C0677FB.88AE4196@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=war@starband.net \
/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