From: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
miklos@szeredi.hu, 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, nikita@clusterfs.com
Subject: Re: [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers
Date: Tue, 27 Feb 2007 09:50:16 +0900 [thread overview]
Message-ID: <45E38048.3020705@hitachi.com> (raw)
In-Reply-To: <20070224134646.0f4edeae.kamezawa.hiroyu@jp.fujitsu.com>
Hi Kamezawa-san,
thanks for your reply.
KAMEZAWA Hiroyuki wrote:
> Interesting, but how about adjust this parameter like below instead of
> adding new control knob ?(this kind of knob is not easy to use.)
>
> ==
> struct writeback_control wbc = {
> .bdi = bdi,
> .sync_mode = WB_SYNC_NONE,
> .older_than_this = NULL,
> .nr_to_write = 0,
> .range_cyclic = 1,
> };
> <snip>
> if (nr_reclaimable) {
> /* Just do what I can do */
> dirty_pages_on_device = count_dirty_pages_on_device_limited(bdi, writechunk);
> wbc.nr_to_write = dirty_pages_on_device.
> writeback_inodes(&wbc);
>
> ==
>
> count_dirty_pages_on_device_limited(bdi, writechunk) above returns
> dirty pages on bdi. if # of dirty_pages on bdi is larger than writechunk,
> just returns writechunk.
I think that way is not enough to control the total amount of
Dirty+Writeback.
In that way, while writeback_inodes() scans for dirty pages and writes
them back, the caller will be blocked only if the length of the write-
requests queue is longer than nr_requests. If so, Writeback may consume
tens MB memory for each queue, because nr_requests is 128 and the
maximum size of a request is 512KB. If you have several devices, it can
consume more than hundred MB memory.
I concerned about that, so I introduced dirty_limit_ratio to limit the
total amount of Dirty+Writeback pages.
Regards
--
Tomoki Sekiyama
Hitachi, Ltd., Systems Development Laboratory
next prev parent reply other threads:[~2007-02-27 0:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-23 12:03 [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers Tomoki Sekiyama
2007-02-24 4:46 ` KAMEZAWA Hiroyuki
2007-02-27 0:50 ` Tomoki Sekiyama [this message]
2007-02-27 1:39 ` KAMEZAWA Hiroyuki
2007-03-02 1:26 ` Tomoki Sekiyama
2007-02-24 13:15 ` Nikita Danilov
2007-02-27 0:52 ` Tomoki Sekiyama
2007-03-01 12:47 ` Leroy van Logchem
2007-03-02 9:16 ` Brice Figureau
2007-03-02 13:06 ` Leroy van Logchem
2007-03-02 16:04 ` Brice Figureau
2007-03-07 13:53 ` Yuji Kakutani
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=45E38048.3020705@hitachi.com \
--to=tomoki.sekiyama.qu@hitachi.com \
--cc=akpm@linux-foundation.org \
--cc=haoki@redhat.com \
--cc=hidehiro.kawai.ez@hitachi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=miklos@szeredi.hu \
--cc=nikita@clusterfs.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