From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Jan Kara <jack@suse.cz>
Cc: Wu Fengguang <fengguang.wu@intel.com>,
Dave Chinner <david@fromorbit.com>,
Andrew Morton <akpm@linux-foundation.org>,
Richard Kennedy <richard@rsk.demon.co.uk>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 4/4] writeback: reduce per-bdi dirty threshold ramp up time
Date: Tue, 24 May 2011 14:24:29 +0200 [thread overview]
Message-ID: <1306239869.2497.50.camel@laptop> (raw)
In-Reply-To: <20110418145929.GH5557@quack.suse.cz>
Sorry for the delay, life got interesting and then it slipped my mind.
On Mon, 2011-04-18 at 16:59 +0200, Jan Kara wrote:
> Your formula is:
> p(j)=\sum_i x_i(j)/(t_i*2^{i+1})
> where $i$ sums from 0 to \infty, x_i(j) is the number of events of type
> $j$ in period $i$, $t_i$ is the total number of events in period $i$.
Actually:
p_j = \Sum_{i=0} (d/dt_i) * x_j / 2^(i+1)
[ discrete differential ]
Where x_j is the total number of events for the j-th element of the set
and t_i is the i-th last period.
Also, the 1/2^(i+1) factor ensures recent history counts heavier while
still maintaining a normalized distribution.
Furthermore, by measuring time in the same measure as the events we get:
t = \Sum_i x_i
which yields that:
p_j = x_j * {\Sum_i (d/dt_i)} * {\Sum 2^(-i-1)}
= x_j * (1/t) * 1
Thus
\Sum_j p_j = \Sum_j x_j / (\Sum_i x_i) = 1
> I want to compute
> l(j)=\sum_i x_i(j)/2^{i+1}
> g=\sum_i t_i/2^{i+1}
> and
> p(j)=l(j)/g
Which gives me:
p_j = x_j * \Sum_i 1/t_i
= x_j / t
Again, if we then measure t in the same events as x, such that:
t = \Sum_i x_i
we again get:
\Sum_j p_j = \Sum_j x_j / \Sum_i x_i = 1
However, if you start measuring t differently that breaks, and the
result is no longer normalized and thus not suitable as a proportion.
Furthermore, while x_j/t is an average, it does not have decaying
history, resulting in past behaviour always affecting current results.
The decaying history thing will ensure that past behaviour will slowly
be 'forgotten' so that when the media is used differently (seeky to
non-seeky workload transition) the slow writeout speed will be forgotten
and we'll end up at the high writeout speed corresponding to less seeks.
Your average will end up hovering in the middle of the slow and fast
modes.
> Clearly, all these values can be computed in O(1).
True, but you get to keep x and t counts over all history, which could
lead to overflow scenarios (although switching to u64 should mitigate
that problem in our lifetime).
> Now for t_i = t for every
> i, the results of both formulas are the same (which is what made me make my
> mistake).
I'm not actually seeing how the averages will be the same, as explained,
yours seems to never forget history.
> But when t_i differ, the results are different.
>From what I can tell, when you stop measuring t in the same events as x
everything comes down because then the sum of proportions isn't
normalized.
> I'd say that the
> new formula also provides a meaningful notion of writeback share although
> it's hard to quantify how far the computations will be in practice...
s/far/fair/ ?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-05-24 12:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 8:59 [PATCH 0/4] trivial writeback fixes Wu Fengguang
2011-04-13 8:59 ` [PATCH 1/4] writeback: add bdi_dirty_limit() kernel-doc Wu Fengguang
2011-04-13 21:47 ` Jan Kara
2011-04-13 8:59 ` [PATCH 2/4] writeback: avoid duplicate balance_dirty_pages_ratelimited() calls Wu Fengguang
2011-04-13 21:53 ` Jan Kara
2011-04-14 0:30 ` Wu Fengguang
2011-04-14 10:20 ` Jan Kara
2011-04-13 8:59 ` [PATCH 3/4] writeback: skip balance_dirty_pages() for in-memory fs Wu Fengguang
2011-04-13 21:54 ` Jan Kara
2011-04-13 8:59 ` [PATCH 4/4] writeback: reduce per-bdi dirty threshold ramp up time Wu Fengguang
2011-04-13 22:04 ` Jan Kara
2011-04-13 23:31 ` Wu Fengguang
2011-04-13 23:52 ` Dave Chinner
2011-04-14 0:23 ` Wu Fengguang
2011-04-14 10:36 ` Richard Kennedy
2011-04-14 13:49 ` Wu Fengguang
2011-04-14 14:08 ` Wu Fengguang
2011-04-14 15:14 ` Wu Fengguang
2011-04-14 15:56 ` Wu Fengguang
2011-04-14 18:16 ` Jan Kara
2011-04-15 3:43 ` Wu Fengguang
2011-04-15 14:37 ` Wu Fengguang
2011-04-15 22:13 ` Jan Kara
2011-04-16 6:05 ` Wu Fengguang
2011-04-16 8:33 ` Peter Zijlstra
2011-04-16 14:21 ` Wu Fengguang
2011-04-17 2:11 ` Wu Fengguang
2011-04-18 14:59 ` Jan Kara
2011-05-24 12:24 ` Peter Zijlstra [this message]
2011-05-24 12:41 ` Peter Zijlstra
2011-06-09 23:58 ` Jan Kara
2011-04-13 10:15 ` [PATCH 0/4] trivial writeback fixes Peter Zijlstra
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=1306239869.2497.50.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=richard@rsk.demon.co.uk \
--cc=riel@redhat.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;
as well as URLs for NNTP newsgroup(s).