On Thu, Aug 25, 2011 at 11:19:34AM +0800, Wu Fengguang wrote: [..] > > So you are trying to make one feedback loop aware of second loop so that > > if second loop is unbalanced, first loop reacts to that as well and not > > just look at dirty_rate and write_bw. So refining new balanced rate by > > pos_ratio helps. > > write_bw > > bdi->dirty_ratelimit_(i+1) = bdi->dirty_ratelimit_i * --------- * pos_ratio > > dirty_bw > > > > Now if global dirty pages are imbalanced, balanced rate will still go > > down despite the fact that dirty_bw == write_bw. This will lead to > > further reduction in task dirty rate. Which in turn will lead to reduced > > number of dirty rate and should eventually lead to pos_ratio=1. > > Right, that's a good alternative viewpoint to the below one. > > write_bw > bdi->dirty_ratelimit_(i+1) = task_ratelimit_i * --------- > dirty_bw > > (1) the periodic rate estimation uses that to refresh the balanced rate on every 200ms > (2) as long as the rate estimation is correct, pos_ratio is able to drive itself to 1.0 Personally I found it much easier to understand the other representation. Once you have come up with equation. balance_rate_(i+1) = balance_rate(i) * write_bw/dirty_bw Can you please put few lines of comments to explain that why above alone is not sufficient and we need to take pos_ratio also in to account to keep number of dirty pages in check. And then go onto balance_rate_(i+1) = balance_rate(i) * write_bw/dirty_bw * pos_ratio This kind of maintains the continuity of explanation and explains that why are we deviating from the theory we discussed so far. > > > A related question though I should have asked you this long back. How does > > throttling based on rate helps. Why we could not just work with two > > pos_ratios. One is gloabl postion ratio and other is bdi position ratio. > > And then throttle task gradually to achieve smooth throttling behavior. > > IOW, what property does rate provide which is not available just by > > looking at per bdi dirty pages. Can't we come up with bdi setpoint and > > limit the way you have done for gloabl setpoint and throttle tasks > > accordingly? > > Good question. If we have no idea of the balanced rate at all, but > still want to limit dirty pages within the range [freerun, limit], > all we can do is to throttle the task at eg. 1TB/s at @freerun and > 0 at @limit. Then you get a really sharp control line which will make > task_ratelimit fluctuate like mad... > > So the balanced rate estimation is the key to get smooth task_ratelimit, > while pos_ratio is the ultimate guarantee for the dirty pages range. Ok, that makes sense. By keeping an estimation of rate at which bdi can write, our range of throttling goes down. Say 0 to 300MB/s instead of 0 to 1TB/sec and that can lead to a more smooth behavior. Thanks Vivek -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>