From: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Cc: Bill Davidsen <davidsen@tmr.com>,
yumiko.sugita.yf@hitachi.com, masami.hiramatsu.pt@hitachi.com,
hidehiro.kawai.ez@hitachi.com, yuji.kakutani.uw@hitachi.com,
soshima@redhat.com, haoki@redhat.com,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH 1/2] VM throttling: Start writeback at dirty_writeback_start_ratio
Date: Tue, 10 Apr 2007 12:04:54 +0900 [thread overview]
Message-ID: <461AFED6.3000407@hitachi.com> (raw)
In-Reply-To: <20070405173125.c1aed842.akpm@linux-foundation.org>
Hello Andrew,
Thank you for your comments.
Andrew Morton wrote:
> On Tue, 03 Apr 2007 19:46:04 +0900
> Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com> wrote:
>> If % of Dirty+Writeback > `dirty_writeback_start_ratio', generators of
>> dirty pages start writeback of dirty pages by themselves. At that time,
>> these processes are not blocked in balance_dirty_pages(), but they may
>> be blocked if the write-requests-queue of the written disk is full
>> (that is, the length of the queue > `nr_requests'). By this behavior,
>> we can throttle only processes which write to the disks with heavy load,
>> and can allow processes to write to the other disks without blocking.
>>
>> If % of Dirty+Writeback > `dirty_ratio', generators of dirty pages
>> are throttled as current Linux does, not to fill up memory with dirty
>> pages.
>
> Does this actually solve the problem? If the request queue is sufficiently
> large (relative to the various dirty-memory thresholds) then I'd expect
> that a heavy-writer will be able to very quickly take the total
> dirty+writeback memory up to the dirty_ratio (should be renamed
> throttle_threshold, but it's too late for that).
>
> I suspect the reason why this patch was successful in your testing was
> because dirty_start_writeback_ratio happens to exceed the size of the disk
> request queues, so the heavy writer is getting stuck on disk request queue
> exhaustion.
>
> But that won't work if we have a lot of processes writing to a lot of
> disks, and it won't work if the request queue size is large, or if the
> dirty-memory thresholds are small (relative to the request queue size).
>
> Do the patches still work after
> `echo 10000 > /sys/block/sda/queue/nr_requests'?
As you pointed out, this patch has no effect if nr_requests is too large,
because it distinguishes heavy disks depending on the length of the write-
requests queue of each disk.
This patch is for providing the system administrators with room to avoid
the problem by adjusting parameters appropriately, rather than an automatic
solution for any possible situations.
Could you please tell me some situations in which we should set nr_request
that large?
Thanks,
--
Tomoki Sekiyama
Hitachi, Ltd., Systems Development Laboratory
next prev parent reply other threads:[~2007-04-10 3:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 12:42 [PATCH 0/3] VM throttling: avoid blocking occasional writers Tomoki Sekiyama
2007-03-14 13:18 ` Peter Zijlstra
2007-03-15 19:07 ` Andrew Morton
2007-03-18 14:59 ` Bill Davidsen
2007-03-22 5:49 ` Tomoki Sekiyama
2007-03-22 11:41 ` Bill Davidsen
2007-03-26 10:27 ` Tomoki Sekiyama
2007-03-26 17:11 ` Bill Davidsen
2007-04-03 10:42 ` Tomoki Sekiyama
2007-04-03 10:46 ` [PATCH 1/2] VM throttling: Start writeback at dirty_writeback_start_ratio Tomoki Sekiyama
2007-04-06 0:31 ` Andrew Morton
2007-04-10 3:04 ` Tomoki Sekiyama [this message]
2007-04-10 3:46 ` Andrew Morton
2007-04-03 10:47 ` [PATCH 2/2] VM throttling: Add vm.dirty_start_writeback_ratio to sysctl Tomoki Sekiyama
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=461AFED6.3000407@hitachi.com \
--to=tomoki.sekiyama.qu@hitachi.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=davidsen@tmr.com \
--cc=haoki@redhat.com \
--cc=hidehiro.kawai.ez@hitachi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=soshima@redhat.com \
--cc=yuji.kakutani.uw@hitachi.com \
--cc=yumiko.sugita.yf@hitachi.com \
/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