From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH 14/45] writeback: quit on wrap for .range_cyclic (afs) Date: Wed, 7 Oct 2009 18:47:11 +0800 Message-ID: <20091007104711.GA11014@localhost> References: <20091007074902.913463607@intel.com> <20091007073818.318088777@intel.com> <32495.1254910626@redhat.com> <20091007102130.GQ30316@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Howells , Andrew Morton , Theodore Tso , Christoph Hellwig , Dave Chinner , Chris Mason , Peter Zijlstra , "Li, Shaohua" , Myklebust Trond , "jens.axboe@oracle.com" , Jan Kara , "linux-fsdevel@vger.kernel.org" , LKML To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <20091007102130.GQ30316@wotan.suse.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Oct 07, 2009 at 06:21:30PM +0800, Nick Piggin wrote: > On Wed, Oct 07, 2009 at 11:17:06AM +0100, David Howells wrote: > > Wu Fengguang wrote: > > > > > Convert wbc.range_cyclic to new behavior: when past EOF, abort writeback > > > of the inode, which instructs writeback_single_inode() to delay it for > > > a while if necessary. > > > > > > It removes one inefficient .range_cyclic IO pattern when writeback_index > > > wraps: > > > submit [10000-10100], (wrap), submit [0-100] > > > In which the submitted pages may be consisted of two distant ranges. > > > > > > It also prevents submitting pointless IO for busy overwriters. > > > > > > CC: David Howells > > > Signed-off-by: Wu Fengguang > > > > Acked-by: David Howells > > I don't see why. Then the inode is given less write bandwidth than > those which don't wrap (or wrap on "nice" boundaries). The "return on wrapped" behavior itself only offers a natural seek boundary to the upper layer. It's mainly the "whether to delay" policy that will affect (overall) bandwidth. If we choose to not sleep, and to go on with other inodes and then back to this inode, no bandwidth will be lost. If we have done work with other inodes (if any), and choose to sleep for a while before restarting this inode, then we could lose bandwidth. The plus side is, we possibly avoid submitting extra IO if this inode is being busy overwritten. So it's a tradeoff. The behavior after this patchset is, to keep busy as long as we can write any pages (in patch 38/45). So we still opt for bandwidth :) Thanks, Fengguang