From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: [PATCH 21/45] writeback: estimate bdi write bandwidth
Date: Wed, 7 Oct 2009 17:39:17 +0800
Message-ID: <20091007093917.GD5646@localhost>
References: <20091007073818.318088777@intel.com> <20091007074903.867171763@intel.com> <1254905599.26976.216.camel@twins>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Theodore Tso <tytso@mit.edu>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	Chris Mason <chris.mason@oracle.com>,
	"Li, Shaohua" <shaohua.li@intel.com>,
	Myklebust Trond <Trond.Myklebust@netapp.com>,
	"jens.axboe@oracle.com" <jens.axboe@oracle.com>,
	Jan Kara <jack@suse.cz>, Nick Piggin <npiggin@suse.de>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mga03.intel.com ([143.182.124.21]:52328 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1757696AbZJGJkK (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 7 Oct 2009 05:40:10 -0400
Content-Disposition: inline
In-Reply-To: <1254905599.26976.216.camel@twins>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Oct 07, 2009 at 04:53:19PM +0800, Peter Zijlstra wrote:
> On Wed, 2009-10-07 at 15:38 +0800, Wu Fengguang wrote:
> > +static void bdi_calc_write_bandwidth(struct backing_dev_info *bdi,
> > +                                    unsigned long nr_pages,
> > +                                    unsigned long time)
> > +{
> > +       unsigned long bw;
> > +
> > +       bw = HZ * nr_pages / (time | 1);
> > +       bdi->write_bandwidth = (bdi->write_bandwidth * 63 + bw) / 64;
> > +}
> 
> If you have block times < 1 jiffy this all falls apart quite quickly.
> You could perhaps try to use cpu_clock() for ns resolution timestamps if
> this is a real issue.

Good point. I'd like to view it in the opposite way: if a sleep takes
<= 1 jiffy to wakeup, that would mean high overheads. We could as well
lift the ratelimit values :)

> (I could imagine fast arrays with huge throughput causing small sleeps,
> resulting in underestimates of their bandwidth)
> 
> Also, 63/64 seems rather slow progress.. maybe that's good.

Whatever will be fast enough for servers that keep running for years. So the
main concern would be how fast it can adapt to slow usb devices.

Here is a quick calculation. Each iteration writes ~800KB:

irb > a=128; 1.upto(100) { |i| a = (a * 63 + 5) / 64; printf "%d\t%d\n", i, a }

[...]
86      12
87      11
88      10
89      9
90      8
91      7
92      6
93      5
94      5

Looks slow. 8 or 16 seems better, which stabilize after writing about
16MB or 32MB data:

a=128; 1.upto(100) { |i| a = (a * 7 + 5) / 8; printf "%d\t%d\n", i, a }
1       112
2       98
3       86
4       75
5       66
6       58
7       51
8       45
9       40
10      35
11      31
12      27
13      24
14      21
15      19
16      17
17      15
18      13
19      12
20      11
21      10
22      9
23      8
24      7
25      6
26      5
27      5
28      5
29      5

16:

34      13
35      12
36      11
37      10
38      9
39      8
40      7
41      6
42      5
43      5

Thanks,
Fengguang