From: Andrew Morton <akpm@osdl.org>
To: Neil Brown <neilb@suse.de>
Cc: David Chinner <dgc@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: RFC - how to balance Dirty+Writeback in the face of slow writeback.
Date: Wed, 16 Aug 2006 23:14:48 -0700 [thread overview]
Message-ID: <20060816231448.cc71fde7.akpm@osdl.org> (raw)
In-Reply-To: <17635.60378.733953.956807@cse.unsw.edu.au>
On Thu, 17 Aug 2006 14:08:58 +1000
Neil Brown <neilb@suse.de> wrote:
> So I think you need to throttle when Dirty+Writeback hits dirty_ratio
yup.
> (which we don't quite get right at the moment). But the trick is to
> throttle gently and fairly, rather than having a hard wall so that any
> one who hits it just stops.
I swear, I had all this working in 2001. Perhaps I dreamed it. But I
specifically remember testing that processes which were performing small,
occasional writes were not getting blocked behind the activity of other
processes which were doing massive write()s. Ho hum, not to worry.
I guess a robust approach would be to track, on a per-process,
per-threadgroup, per-user, etc basis the time-averaged page-dirtying rate.
If it is "low" then accept the dirtying. If it is "high" then this process
is a heavy writer and needs throttling earlier. Up to a point - at some
level we'll need to throttle everyone as a safety net if nothing else.
Something like that covers the global dirty+writeback problem. The other
major problem space is the multiple-backing-device problem:
a) One device is being written to heavily, another lightly
b) One device is fast, another is slow.
Thus far, the limited size of the request queues has saved us from really,
really serious problems. But that doesn't work when lots of disks are
being used. To solve this properly we'd need to account for
dirty+writeback(+unstable?) pages on a per-backing-dev basis.
But as a first step, yes, using dirty+writeback for the throttling
threshold and continuing to rely upon limited request queue size to save us
from disaster would be a good step.
btw, one thing which afaik NFS _still_ doesn't do is to wake up processes
which are stuck in blk_congestion_wait() when NFS has retired a bunch of
writes. It should do so, otherwise NFS write-intensive workloads might end
up sleeping for too long. I guess the amount of buffering and hysteresis
we have in there has thus far prevented any problems from being observed.
next prev parent reply other threads:[~2006-08-17 6:14 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-14 23:40 Neil Brown
2006-08-15 8:06 ` Andrew Morton
2006-08-15 23:00 ` David Chinner
2006-08-17 4:08 ` Neil Brown
2006-08-17 6:14 ` Andrew Morton [this message]
2006-08-17 12:36 ` Trond Myklebust
2006-08-17 15:14 ` Andrew Morton
2006-08-17 16:22 ` Trond Myklebust
2006-08-18 5:49 ` Andrew Morton
2006-08-18 10:43 ` Nikita Danilov
2006-08-18 0:11 ` David Chinner
2006-08-18 6:29 ` Andrew Morton
2006-08-18 7:03 ` Jens Axboe
2006-08-18 7:11 ` Andrew Morton
2006-08-18 18:57 ` Andi Kleen
2006-08-21 0:35 ` Neil Brown
2006-08-21 3:15 ` David Chinner
2006-08-21 7:24 ` Neil Brown
2006-08-21 13:51 ` Jens Axboe
2006-08-25 4:36 ` Neil Brown
2006-08-25 6:37 ` Jens Axboe
2006-08-28 1:28 ` David Chinner
2006-08-25 13:16 ` Trond Myklebust
2006-08-27 8:21 ` Neil Brown
2006-08-21 14:28 ` David Chinner
2006-08-25 5:24 ` Neil Brown
2006-08-28 1:55 ` David Chinner
2006-08-21 7:47 ` Andi Kleen
2006-08-18 7:07 ` Neil Brown
2006-08-17 22:17 ` David Chinner
2006-08-17 3:59 ` Neil Brown
2006-08-17 6:22 ` Andrew Morton
2006-08-17 8:36 ` Jens Axboe
2006-08-17 13:21 ` Trond Myklebust
2006-08-17 15:30 ` Andrew Morton
2006-08-17 16:18 ` Trond Myklebust
2006-08-18 5:34 ` Andrew Morton
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=20060816231448.cc71fde7.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dgc@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.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
Powered by JetHome