From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: +
	mm-balance_dirty_pages-reduce-calls-to-global_page_state-to-reduce-c
	ache-references.patch added to -mm tree
Date: Sun, 23 Aug 2009 15:27:06 +0800
Message-ID: <20090823072705.GA4028@localhost>
References: <200908212250.n7LMox3g029154@imap1.linux-foundation.org> <20090822025150.GB7798@localhost> <1250964701.7538.101.camel@twins> <20090823013252.GA7661@localhost> <1251005477.7538.104.camel@twins>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mm-commits@vger.kernel.org" <mm-commits@vger.kernel.org>,
	"richard@rsk.demon.co.uk" <richard@rsk.demon.co.uk>,
	"chris.mason@oracle.com" <chris.mason@oracle.com>,
	"jens.axboe@oracle.com" <jens.axboe@oracle.com>,
	"mbligh@mbligh.org" <mbligh@mbligh.org>,
	"miklos@szeredi.hu" <miklos@szeredi.hu>,
	"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]:28287 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752326AbZHWH1P (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 23 Aug 2009 03:27:15 -0400
Content-Disposition: inline
In-Reply-To: <1251005477.7538.104.camel@twins>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Aug 23, 2009 at 01:31:17PM +0800, Peter Zijlstra wrote:
> On Sun, 2009-08-23 at 09:32 +0800, Wu Fengguang wrote:
> > > > I'd propose to remove the above 'if' and liberate the following three 'if's.
> > > 
> > > That might work, but it looses the total dirty_thresh constraint. The
> > > sum of per-bdi dirties _should_ not be larger than that, but I'm not
> > > sure it won't ever be.
> > > 
> > > The clip code Richard removed ensured that, and I think I wrote that out
> > > of more than sheer paranoia, but I'm not sure anymore :/
> > 
> > Oh I assumed that your per-bdi throttling is not too permissive to
> > exceed the global dirty_thresh. In theory the per-bdi throttling
> > should be able to quickly stop the growing of (nr_reclaimable +
> > nr_writeback).  Once dirty_thresh is reached we already los
> 
> Right, so:
> 
>  bdi_thresh_n = dirty_thresh * p(n) + eps.
> 
> and
> 
>  \Sum_n p(n) = 1
> 
> So:
> 
>  \Sum_n bdi_thresh_n = dirty_thresh + n*eps
> 
> Which yields an O(n) error bound.
> 
> I'm just not sure how large the thing is in reality, and paranoia won
> out.

A wild question: is it possible to make the equation:

        bdi_thresh_n = dirty_thresh * p(n) - eps.

?