From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Richard Kennedy <richard@rsk.demon.co.uk>
Cc: Wu Fengguang <fengguang.wu@intel.com>,
lkml <linux-kernel@vger.kernel.org>,
Martin Bligh <mbligh@google.com>
Subject: Re: bdi_threshold slow to reach steady state
Date: Wed, 14 Oct 2009 13:37:52 +0200 [thread overview]
Message-ID: <1255520272.8392.429.camel@twins> (raw)
In-Reply-To: <1255518586.2360.78.camel@castor>
On Wed, 2009-10-14 at 12:09 +0100, Richard Kennedy wrote:
> Hi Peter,
>
> I've been running simple tests that uses fio to write 2Gb & reading the
> bdi dirty threshold once a second from debugfs.
>
> The graph of bdi dirty threshold is nice and smooth but takes a long
> time to reach a steady state, 60 seconds or more. (run on 2.6.32-rc4)
>
> By eye it seems as though a first-order control system is a good model
> for its behavior, so it approximates to 1-e^(-t/T). It just seems too
> heavily damped ( at least on my machine).
>
> For fun, I changed calc_period_shift to
> return ilog2(dirty_total - 1) - 2;
>
> and it now reaches a steady state much quicker, around 4-5 seconds.
>
> Tests that write to 2 disks at the same time show no significant
> performance differences but are much more consistent, i.e. the standard
> deviation is lower across multiple runs.
>
> I have noticed that the first test run on a freshly booted machine is
> always the slowest of any sequence of tests, but this change to
> calc_period_shift greatly reduces this effect.
>
> So I wondered how you chose these values? and are there any other tests
> that are useful to explore this?
Right, so we measure time in page writeback completions, and the measure
I used was the round up power of two of the dirty_thresh. We adjust in
the same time it takes to write out a full dirty_thresh amount of data.
The idea was that people would scale their dirty thesh according to
their writeout capacity, etc..
Martin J Bligh complained about this very same issue and I told them to
experiment with that same scale function. But I guess the result of that
got lost in the google filter (stuff goes in, nothing ever comes back
out).
Anyway, the dirty_thresh relation seems sensible still, but the exact
parameters could be poked at. I have no objection to reducing the period
with a factor of 16 like you did, except that we need some more
feedback, preferably from people with more than a few spindles.
(The initial ramp will be roughly twice as slow, since the steady state
of this approximation is half-full).
> I know that my machine is getting a bit old now, it's AMDX2 & only has
> sata 150 drives, so I'm not suggesting that this change is going to be
> correct for all machines but maybe we can set a better default? or take
> more factors in to account other than just memory size.
>
> BTW why is it ilog2(dirty_total -1) -- what does the -1 do?
http://lkml.org/lkml/2007/1/26/143
next prev parent reply other threads:[~2009-10-14 11:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 11:09 bdi_threshold slow to reach steady state Richard Kennedy
2009-10-14 11:37 ` Peter Zijlstra [this message]
2009-10-14 13:55 ` Richard Kennedy
2009-10-14 14:04 ` Peter Zijlstra
2009-10-15 9:22 ` Richard Kennedy
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=1255520272.8392.429.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=richard@rsk.demon.co.uk \
/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.