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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
