From: Andrew Morton <akpm@linux-foundation.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/7] writeback: introduce max-pause and pass-good dirty limits
Date: Tue, 21 Jun 2011 17:20:43 -0700 [thread overview]
Message-ID: <20110621172043.51621aa9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20110619150510.367141119@intel.com>
On Sun, 19 Jun 2011 23:01:12 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:
> The max-pause limit helps to keep the sleep time inside
> balance_dirty_pages() within 200ms. The 200ms max sleep means per task
> rate limit of 8pages/200ms=160KB/s, which normally is enough to stop
> dirtiers from continue pushing the dirty pages high, unless there are
> a sufficient large number of slow dirtiers (ie. 500 tasks doing 160KB/s
> will still sum up to 80MB/s, reaching the write bandwidth of a slow disk).
>
> The pass-good limit helps to let go of the good bdi's in the presence of
> a blocked bdi (ie. NFS server not responding) or slow USB disk which for
> some reason build up a large number of initial dirty pages that refuse
> to go away anytime soon.
The hard-wired numbers and hard-wired assumptions about device speeds
shouldn't be here at all. They will be sub-optimal (and sometimes
extremely so) for all cases. They will become wronger over time. Or
less wrong, depending upon which way they were originally wrong.
> + dirty_thresh = hard_dirty_limit(dirty_thresh);
> + if (nr_dirty < dirty_thresh + dirty_thresh / DIRTY_MAXPAUSE &&
> + jiffies - start_time > MAX_PAUSE)
> + break;
> + if (nr_dirty < dirty_thresh + dirty_thresh / DIRTY_PASSGOOD &&
> + bdi_dirty < bdi_thresh)
> + break;
It appears that despite their similarity, DIRTY_MAXPAUSE is a
dimensionless value whereas the units of MAX_PAUSE is jiffies. Perhaps
more care in naming choices would clarify things like this.
The first comparison might be clearer if it used time_after().
Both statements need comments explaining what they do and *why they do
it*.
next prev parent reply other threads:[~2011-06-22 0:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 15:01 [PATCH 0/7] more writeback patches for 3.1 Wu Fengguang
2011-06-19 15:01 ` [PATCH 1/7] writeback: consolidate variable names in balance_dirty_pages() Wu Fengguang
2011-06-20 7:45 ` Christoph Hellwig
2011-06-19 15:01 ` [PATCH 2/7] writeback: add parameters to __bdi_update_bandwidth() Wu Fengguang
2011-06-19 15:31 ` Christoph Hellwig
2011-06-19 15:35 ` Wu Fengguang
2011-06-19 15:01 ` [PATCH 3/7] writeback: introduce smoothed global dirty limit Wu Fengguang
2011-06-19 15:36 ` Christoph Hellwig
2011-06-19 15:55 ` Wu Fengguang
2011-06-21 23:59 ` Andrew Morton
2011-06-22 14:11 ` Wu Fengguang
2011-06-20 21:18 ` Jan Kara
2011-06-21 14:24 ` Wu Fengguang
2011-06-22 0:04 ` Andrew Morton
2011-06-22 14:24 ` Wu Fengguang
2011-06-19 15:01 ` [PATCH 4/7] writeback: introduce max-pause and pass-good dirty limits Wu Fengguang
2011-06-22 0:20 ` Andrew Morton [this message]
2011-06-23 13:18 ` Wu Fengguang
2011-06-19 15:01 ` [PATCH 5/7] writeback: make writeback_control.nr_to_write straight Wu Fengguang
2011-06-19 15:35 ` Christoph Hellwig
2011-06-19 16:14 ` Wu Fengguang
2011-06-19 15:01 ` [PATCH 6/7] writeback: scale IO chunk size up to half device bandwidth Wu Fengguang
2011-06-19 15:01 ` [PATCH 7/7] writeback: timestamp based bdi dirty_exceeded state Wu Fengguang
2011-06-20 20:09 ` Christoph Hellwig
2011-06-21 10:00 ` Steven Whitehouse
2011-06-20 21:38 ` Jan Kara
2011-06-21 15:07 ` Wu Fengguang
2011-06-21 21:14 ` Jan Kara
2011-06-22 14:37 ` Wu Fengguang
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=20110621172043.51621aa9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.