On Fri, Aug 26, 2011 at 05:04:29PM +0800, Peter Zijlstra wrote: > On Fri, 2011-08-26 at 08:18 +0800, Wu Fengguang wrote: > > On Thu, Aug 25, 2011 at 12:12:58AM +0800, Peter Zijlstra wrote: > > > On Wed, 2011-08-24 at 08:12 +0800, Wu Fengguang wrote: > > > > > Put (6) into (4), we get > > > > > > > > balanced_rate_(i+1) = balanced_rate_(i) * 2 > > > > = (write_bw / N) * 2 > > > > > > > > That means, any position imbalance will lead to balanced_rate > > > > estimation errors if we follow (4). Whereas if (1)/(5) is used, we > > > > always get the right balanced dirty ratelimit value whether or not > > > > (pos_ratio == 1.0), hence make the rate estimation independent(*) of > > > > dirty position control. > > > > > > > > (*) independent as in real values, not the seemingly relations in equation > > > > > > > > > The assumption here is that N is a constant.. in the above case > > > pos_ratio would eventually end up at 1 and things would be good again. I > > > see your argument about oscillations, but I think you can introduce > > > similar effects by varying N. > > > > Yeah, it's very possible for N to change over time, in which case > > balanced_rate will adapt to new N in similar way. > > Gah.. but but but, that gives the same stuff as your (6)+(4). Why won't > you accept that for pos_ratio but you don't mind for N ? Sorry I'm now feeling lost...anyway it's convenient to try out the pure rate feedback. And the test case exactly includes the sudden change of N. I'm now running the tests with this trivial patch: --- linux-next.orig/mm/page-writeback.c 2011-08-26 17:58:01.000000000 +0800 +++ linux-next/mm/page-writeback.c 2011-08-26 17:59:06.000000000 +0800 @@ -800,7 +800,7 @@ static void bdi_update_dirty_ratelimit(s * the dirty count meet the setpoint, but also where the slope of * pos_ratio is most flat and hence task_ratelimit is least fluctuated. */ - balanced_dirty_ratelimit = div_u64((u64)task_ratelimit * write_bw, + balanced_dirty_ratelimit = div_u64((u64)dirty_ratelimit * write_bw, dirty_rate | 1); /* -- 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
