From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751568Ab1IBMRI (ORCPT ); Fri, 2 Sep 2011 08:17:08 -0400 Received: from merlin.infradead.org ([205.233.59.134]:45161 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860Ab1IBMRG convert rfc822-to-8bit (ORCPT ); Fri, 2 Sep 2011 08:17:06 -0400 Subject: Re: [PATCH 2/5] writeback: dirty position control From: Peter Zijlstra To: Wu Fengguang Cc: Vivek Goyal , "linux-fsdevel@vger.kernel.org" , Andrew Morton , Jan Kara , Christoph Hellwig , Dave Chinner , Greg Thelen , Minchan Kim , Andrea Righi , linux-mm , LKML Date: Fri, 02 Sep 2011 14:16:40 +0200 In-Reply-To: <20110829133729.GA27871@localhost> References: <1313154259.6576.42.camel@twins> <20110812142020.GB17781@localhost> <1314027488.24275.74.camel@twins> <20110823034042.GC7332@localhost> <1314093660.8002.24.camel@twins> <20110823141504.GA15949@localhost> <20110823174757.GC15820@redhat.com> <20110824001257.GA6349@localhost> <20110824180058.GC22434@redhat.com> <1314623527.2816.28.camel@twins> <20110829133729.GA27871@localhost> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Mailer: Evolution 3.0.2- Message-ID: <1314965800.1301.7.camel@twins> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2011-08-29 at 21:37 +0800, Wu Fengguang wrote: > > > > Ok so this argument makes sense, is there some formalism to describe > > such systems where such things are more evident? > > I find the most easy and clean way to describe it is, > > (1) the below formula > write_bw > bdi->dirty_ratelimit_(i+1) = bdi->dirty_ratelimit_i * --------- * pos_ratio > dirty_bw > is able to yield > > dirty_ratelimit_(i) ~= (write_bw / N) > > as long as > > - write_bw, dirty_bw and pos_ratio are not changing rapidly > - dirty pages are not around @freerun or @limit > > Otherwise there will be larger estimation errors. > > (2) based on (1), we get > > task_ratelimit ~= (write_bw / N) * pos_ratio > > So the pos_ratio feedback is able to drive dirty count to the > setpoint, where pos_ratio = 1. > > That interpretation based on _real values_ can neatly decouple the two > feedback loops :) It makes full utilization of the fact "the > dirty_ratelimit _value_ is independent on pos_ratio except for > possible impacts on estimation errors". OK, so the 'problem' I have with this is that the whole control thing really doesn't care about N. All it does is measure: - dirty rate - writeback rate observe: - dirty count; with the independent input of its setpoint control: - ratelimit so I was looking for a way to describe the interaction between the two feedback loops without involving the exact details of what they're controlling, but that might just end up being an oxymoron. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 2/5] writeback: dirty position control Date: Fri, 02 Sep 2011 14:16:40 +0200 Message-ID: <1314965800.1301.7.camel@twins> References: <1313154259.6576.42.camel@twins> <20110812142020.GB17781@localhost> <1314027488.24275.74.camel@twins> <20110823034042.GC7332@localhost> <1314093660.8002.24.camel@twins> <20110823141504.GA15949@localhost> <20110823174757.GC15820@redhat.com> <20110824001257.GA6349@localhost> <20110824180058.GC22434@redhat.com> <1314623527.2816.28.camel@twins> <20110829133729.GA27871@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: Vivek Goyal , "linux-fsdevel@vger.kernel.org" , Andrew Morton , Jan Kara , Christoph Hellwig , Dave Chinner , Greg Thelen , Minchan Kim , Andrea Righi , linux-mm , LKML To: Wu Fengguang Return-path: In-Reply-To: <20110829133729.GA27871@localhost> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 2011-08-29 at 21:37 +0800, Wu Fengguang wrote: > >=20 > > Ok so this argument makes sense, is there some formalism to describe > > such systems where such things are more evident? >=20 > I find the most easy and clean way to describe it is, >=20 > (1) the below formula > write_bw =20 > bdi->dirty_ratelimit_(i+1) =3D bdi->dirty_ratelimit_i * --------- * p= os_ratio > dirty_bw > is able to yield >=20 > dirty_ratelimit_(i) ~=3D (write_bw / N) >=20 > as long as >=20 > - write_bw, dirty_bw and pos_ratio are not changing rapidly > - dirty pages are not around @freerun or @limit >=20 > Otherwise there will be larger estimation errors. >=20 > (2) based on (1), we get >=20 > task_ratelimit ~=3D (write_bw / N) * pos_ratio >=20 > So the pos_ratio feedback is able to drive dirty count to the > setpoint, where pos_ratio =3D 1. >=20 > That interpretation based on _real values_ can neatly decouple the two > feedback loops :) It makes full utilization of the fact "the > dirty_ratelimit _value_ is independent on pos_ratio except for > possible impacts on estimation errors".=20 OK, so the 'problem' I have with this is that the whole control thing really doesn't care about N. All it does is measure: - dirty rate - writeback rate observe: - dirty count; with the independent input of its setpoint control: - ratelimit so I was looking for a way to describe the interaction between the two feedback loops without involving the exact details of what they're controlling, but that might just end up being an oxymoron. -- 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: email@kvack.org