Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757267AbZCYVwX (ORCPT ); Wed, 25 Mar 2009 17:52:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755196AbZCYVwP (ORCPT ); Wed, 25 Mar 2009 17:52:15 -0400 Received: from THUNK.ORG ([69.25.196.29]:38910 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753667AbZCYVwO (ORCPT ); Wed, 25 Mar 2009 17:52:14 -0400 Date: Wed, 25 Mar 2009 17:51:37 -0400 From: Theodore Tso To: Linus Torvalds Cc: Jan Kara , Andrew Morton , Ingo Molnar , Alan Cox , Arjan van de Ven , Peter Zijlstra , Nick Piggin , Jens Axboe , David Rees , Jesper Krogh , Linux Kernel Mailing List Subject: Re: Linux 2.6.29 Message-ID: <20090325215137.GQ32307@mit.edu> Mail-Followup-To: Theodore Tso , Linus Torvalds , Jan Kara , Andrew Morton , Ingo Molnar , Alan Cox , Arjan van de Ven , Peter Zijlstra , Nick Piggin , Jens Axboe , David Rees , Jesper Krogh , Linux Kernel Mailing List References: <20090324091545.758d00f5@lxorguk.ukuu.org.uk> <20090324093245.GA22483@elte.hu> <20090324101011.6555a0b9@lxorguk.ukuu.org.uk> <20090324103111.GA26691@elte.hu> <20090324041249.1133efb6.akpm@linux-foundation.org> <20090325123744.GK23439@duck.suse.cz> <20090325150041.GM32307@mit.edu> <20090325185824.GO32307@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 833 Lines: 19 On Wed, Mar 25, 2009 at 01:45:43PM -0700, Linus Torvalds wrote: > > The third potential solution we can try doing is to make some tuning > > adjustments to the VM so that we start pushing out these data blocks > > much more aggressively out to the disk. > > Yes. but at least one problem is, as mentioned, that when the VM calls > writepage[s]() to start async writeback, many filesystems do seem to just > _block_ on it. Um, no, ext3 shouldn't block on writepage(). Since it doesn't do delayed allocation, it should always be able to push out a dirty page to the disk. - Ted -- 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/