All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.