From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754056Ab1EFDgA (ORCPT ); Thu, 5 May 2011 23:36:00 -0400 Received: from mga11.intel.com ([192.55.52.93]:16211 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664Ab1EFDf6 (ORCPT ); Thu, 5 May 2011 23:35:58 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.64,324,1301900400"; d="scan'208";a="918710247" Message-Id: <20110506031612.294824260@intel.com> User-Agent: quilt/0.48-1 Date: Fri, 06 May 2011 11:08:25 +0800 From: Wu Fengguang To: Andrew Morton Cc: Wu Fengguang , LKML , Jan Kara cc: Dave Chinner cc: Christoph Hellwig cc: Subject: [PATCH 04/17] writeback: try more writeback as long as something was written References: <20110506030821.523093711@intel.com> Content-Disposition: inline; filename=writeback-background-retry.patch Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org writeback_inodes_wb()/__writeback_inodes_sb() are not aggressive in that they only populate possibly a subset of eligible inodes into b_io at entrance time. When the queued set of inodes are all synced, they just return, possibly with all queued inode pages written but still wbc.nr_to_write > 0. For kupdate and background writeback, there may be more eligible inodes sitting in b_dirty when the current set of b_io inodes are completed. So it is necessary to try another round of writeback as long as we made some progress in this round. When there are no more eligible inodes, no more inodes will be enqueued in queue_io(), hence nothing could/will be synced and we may safely bail. For example, imagine 100 inodes i0, i1, i2, ..., i90, i91, i99 At queue_io() time, i90-i99 happen to be expired and moved to s_io for IO. When finished successfully, if their total size is less than MAX_WRITEBACK_PAGES, nr_to_write will be > 0. Then wb_writeback() will quit the background work (w/o this patch) while it's still over background threshold. This will be a fairly normal/frequent case I guess. Jan raised the concern I'm just afraid that in some pathological cases this could result in bad writeback pattern - like if there is some process which manages to dirty just a few pages while we are doing writeout, this looping could result in writing just a few pages in each round which is bad for fragmentation etc. However it requires really strong timing to make that to (continuously) happen. In practice it's very hard to produce such a pattern even if there is such a possibility in theory. I actually tried to write 1 page per 1ms with this command write-and-fsync -n10000 -S 1000 -c 4096 /fs/test and do sync(1) at the same time. The sync completes quickly on ext4, xfs, btrfs. The readers could try other write-and-sleep patterns and check if it can block sync for longer time. CC: Jan Kara Signed-off-by: Wu Fengguang --- fs/fs-writeback.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) --- linux-next.orig/fs/fs-writeback.c 2011-05-05 23:30:24.000000000 +0800 +++ linux-next/fs/fs-writeback.c 2011-05-05 23:30:25.000000000 +0800 @@ -739,23 +739,23 @@ static long wb_writeback(struct bdi_writ wrote += write_chunk - wbc.nr_to_write; /* - * If we consumed everything, see if we have more + * Did we write something? Try for more + * + * Dirty inodes are moved to b_io for writeback in batches. + * The completion of the current batch does not necessarily + * mean the overall work is done. So we keep looping as long + * as made some progress on cleaning pages or inodes. */ - if (wbc.nr_to_write <= 0) + if (wbc.nr_to_write < write_chunk) continue; if (wbc.inodes_cleaned) continue; /* - * Didn't write everything and we don't have more IO, bail + * No more inodes for IO, bail */ if (!wbc.more_io) break; /* - * Did we write something? Try for more - */ - if (wbc.nr_to_write < write_chunk) - continue; - /* * Nothing written. Wait for some inode to * become available for writeback. Otherwise * we'll just busyloop.