From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 02/35] writeback: safety margin for bdi stat error Date: Thu, 13 Jan 2011 11:38:34 +0100 Message-ID: <20110113103834.GA5008@quack.suse.cz> References: <20101213144646.341970461@intel.com> <20101213150326.604451840@intel.com> <20110112215949.GD14260@quack.suse.cz> <20110113041440.GC7840@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Andrew Morton , Peter Zijlstra , Christoph Hellwig , Trond Myklebust , Dave Chinner , Theodore Ts'o , Chris Mason , Mel Gorman , Rik van Riel , KOSAKI Motohiro , Greg Thelen , Minchan Kim , linux-mm , "linux-fsdevel@vger.kernel.org" , LKML To: Wu Fengguang Return-path: Content-Disposition: inline In-Reply-To: <20110113041440.GC7840@localhost> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Thu 13-01-11 12:14:40, Wu Fengguang wrote: > On Thu, Jan 13, 2011 at 05:59:49AM +0800, Jan Kara wrote: > > > So the root cause is, the bdi_dirty is well under the global nr_dirty > > > due to accounting errors. This can be fixed by using bdi_stat_sum(), > > So which statistic had the big error? I'd just like to understand > > this (and how come your patch improves the situation)... > > bdi_stat_error() = nr_cpu_ids * BDI_STAT_BATCH > = 8 * (8*(1+ilog2(8))) > = 8 * 8 * 4 > = 256 pages > = 1MB Yes, my question was more aiming at on which statistics the error happens so that it causes problems for you. Thinking about it now I suppose you observe that bdi_nr_writeback + bdi_nr_reclaimable < bdi_thresh but in fact the number of pages is higher than bdi_thresh because of accounting errors. And thus we are able to reach global dirty limit and the tasks get throttled heavily. Am I right? Honza -- Jan Kara SUSE Labs, CR -- 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 policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: email@kvack.org