From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH 01/45] writeback: reduce calls to global_page_state in balance_dirty_pages() Date: Sun, 11 Oct 2009 09:44:40 +0200 Message-ID: <1255247080.11081.3.camel@twins> References: <20091007073818.318088777@intel.com> <20091007074901.251116016@intel.com> <20091009151230.GF7654@duck.suse.cz> <1255101512.8802.65.camel@laptop> <20091009154759.GJ7654@duck.suse.cz> <20091011022813.GA21315@localhost> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Jan Kara , Andrew Morton , Theodore Tso , Christoph Hellwig , Dave Chinner , Chris Mason , "Li, Shaohua" , Myklebust Trond , "jens.axboe@oracle.com" , Nick Piggin , "linux-fsdevel@vger.kernel.org" , Richard Kennedy , LKML To: Wu Fengguang Return-path: Received: from viefep13-int.chello.at ([62.179.121.33]:54025 "EHLO viefep13-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751332AbZJKHpN (ORCPT ); Sun, 11 Oct 2009 03:45:13 -0400 In-Reply-To: <20091011022813.GA21315@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 2009-10-11 at 10:28 +0800, Wu Fengguang wrote: > > Note that the total limit check itself may not be sufficient. For > example, there are no nr_writeback limit for NFS (and maybe btrfs) > after removing the congestion waits. Therefore it is very possible > > nr_writeback => dirty_thresh > nr_dirty => 0 > > which is obviously undesirable: everything newly dirtied are soon put > to writeback. It violates the 30s expire time and the background > threshold rules, and will hurt write-and-truncate operations (ie. temp > files). > > So the better solution would be to impose a nr_writeback limit for > every filesystem that didn't already have one (the block io queue). > NFS used to have that limit with congestion_wait, but now we need > to do a wait queue for it. > > With the nr_writeback wait queue, it can be guaranteed that once > balance_dirty_pages() asks for writing 1500 pages, it will be done > with necessary sleeping in the bdi flush thread. So we can safely > remove the loop and double checking of global dirty limit in > balance_dirty_pages(). nr_reclaim = nr_dirty + nr_writeback + nr_unstable, so anything calling into balance_dirty_pages() would still block on seeing such large amounts of nr_writeback. Having the constraint nr_dirty + nr_writeback + nr_unstable < dirty_thresh should ensure we never have nr_writeback > dirty_thresh, simply because you cannot dirty more, which then cannot be converted to more writeback. Or am I missing something?