From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 03/15] writeback: introduce
 writeback_control.inodes_cleaned
Date: Tue, 7 Jun 2011 16:03:13 -0700
Message-ID: <20110607160313.86fb31df.akpm@linux-foundation.org>
References: <20110607213236.634026193@intel.com>
	<20110607213853.757201783@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Jan Kara <jack@suse.cz>, Mel Gorman <mel@csn.ul.ie>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	<linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
To: Wu Fengguang <fengguang.wu@intel.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20110607213853.757201783@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Wed, 08 Jun 2011 05:32:39 +0800
Wu Fengguang <fengguang.wu@intel.com> wrote:

> The flusher works on dirty inodes in batches, and may quit prematurely
> if the batch of inodes happen to be metadata-only dirtied: in this case
> wbc->nr_to_write won't be decreased at all, which stands for "no pages
> written" but also mis-interpreted as "no progress".
> 
> So introduce writeback_control.inodes_cleaned to count the inodes get
> cleaned.  A non-zero value means there are some progress on writeback,
> in which case more writeback can be tried.

Yes, that makes sense.  I had a workload which demonstrated/exploited
this nine years ago but I never got around to fixing it, never told
anyone and nobody noticed ;)

> +	long inodes_cleaned;		/* # of inodes cleaned */

nanonit: I'd call this inodes_written, because they may not actually be
clean.