Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757503Ab0FOXU6 (ORCPT ); Tue, 15 Jun 2010 19:20:58 -0400 Received: from bld-mail13.adl6.internode.on.net ([150.101.137.98]:56104 "EHLO mail.internode.on.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754908Ab0FOXU5 (ORCPT ); Tue, 15 Jun 2010 19:20:57 -0400 Date: Wed, 16 Jun 2010 09:20:09 +1000 From: Dave Chinner To: Nick Piggin Cc: Evgeniy Polyakov , Andrew Morton , Mel Gorman , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Chris Mason , Rik van Riel , Johannes Weiner , Christoph Hellwig , KAMEZAWA Hiroyuki Subject: Re: [PATCH 11/12] vmscan: Write out dirty pages in batch Message-ID: <20100615232009.GT6590@dastard> References: <1276514273-27693-12-git-send-email-mel@csn.ul.ie> <20100614231144.GG6590@dastard> <20100614162143.04783749.akpm@linux-foundation.org> <20100615003943.GK6590@dastard> <20100614183957.ad0cdb58.akpm@linux-foundation.org> <20100615032034.GR6590@dastard> <20100614211515.dd9880dc.akpm@linux-foundation.org> <20100615063643.GS6590@dastard> <20100615102822.GA4010@ioremap.net> <20100615105538.GI6138@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100615105538.GI6138@laptop> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1304 Lines: 32 On Tue, Jun 15, 2010 at 08:55:38PM +1000, Nick Piggin wrote: > On Tue, Jun 15, 2010 at 02:28:22PM +0400, Evgeniy Polyakov wrote: > > On Tue, Jun 15, 2010 at 04:36:43PM +1000, Dave Chinner (david@fromorbit.com) wrote: > > Per-mapping sorting will not do anything good in this case, even if > > files were previously created in a good facion being placed closely and > > so on, and only block layer will find a correlation between adjacent > > blocks in different files. But with existing queue management it has > > quite a small opportunity, and that's what I think Andrew is arguing > > about. > > The solution is not to sort pages on their way to be submitted either, > really. > > What I do in fsblock is to maintain a block-nr sorted tree of dirty > blocks. This works nicely because fsblock dirty state is properly > synchronized with page dirty state. How does this work with delayed allocation where there is no block number associated with the page until writeback calls the allocation routine? Cheers, Dave. -- Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/