Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763767AbXEVV3Q (ORCPT ); Tue, 22 May 2007 17:29:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758750AbXEVV3A (ORCPT ); Tue, 22 May 2007 17:29:00 -0400 Received: from waste.org ([66.93.16.53]:35684 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757023AbXEVV27 (ORCPT ); Tue, 22 May 2007 17:28:59 -0400 Date: Tue, 22 May 2007 16:25:24 -0500 From: Matt Mackall To: Andrew Morton Cc: Chris Mason , Chuck Ebbert , linux-kernel@vger.kernel.org Subject: Re: filesystem benchmarking fun Message-ID: <20070522212524.GD11166@waste.org> References: <20070516171156.GY26766@think.oraclecorp.com> <20070516112515.b6f247b2.akpm@linux-foundation.org> <20070516191339.GA26766@think.oraclecorp.com> <20070516123342.714a11d8.akpm@linux-foundation.org> <20070516195359.GE26766@think.oraclecorp.com> <20070516130413.1fd391bf.akpm@linux-foundation.org> <20070516201414.GF26766@think.oraclecorp.com> <20070516133726.0c68a65f.akpm@linux-foundation.org> <20070522163511.GB6138@think.oraclecorp.com> <20070522112120.4a5c6a5d.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070522112120.4a5c6a5d.akpm@linux-foundation.org> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 49 On Tue, May 22, 2007 at 11:21:20AM -0700, Andrew Morton wrote: > On Tue, 22 May 2007 12:35:11 -0400 > Chris Mason wrote: > > > On Wed, May 16, 2007 at 01:37:26PM -0700, Andrew Morton wrote: > > > On Wed, 16 May 2007 16:14:14 -0400 > > > Chris Mason wrote: > > > > > > > On Wed, May 16, 2007 at 01:04:13PM -0700, Andrew Morton wrote: > > > > > > The good news is that if you let it run long enough, the times > > > > > > stabilize. The bad news is: > > > > > > > > > > > > create dir kernel-86 222MB in 15.85 seconds (14.03 MB/s) > > > > > > create dir kernel-87 222MB in 28.67 seconds (7.76 MB/s) > > > > > > create dir kernel-88 222MB in 18.12 seconds (12.27 MB/s) > > > > > > create dir kernel-89 222MB in 19.77 seconds (11.25 MB/s) > > > > > > > > > > well hang on. Doesn't this just mean that the first few runs were writing > > > > > into pagecache and the later ones were blocking due to dirty-memory limits? > > > > > > > > > > Or do you have a sync in there? > > > > > > > > > There's no sync, but if you watch vmstat you can clearly see the log > > > > flushes, even when the overall create times are 11MB/s. vmstat goes > > > > 30MB/s -> 4MB/s or less, then back up to 30MB/s. > > > > > > How do you know that it is a log flush rather than, say, pdflush > > > hitting the blockdev inode and doing a big seeky write? > > > > Ok, I did some more work to split out the two cases (block device inode > > writeback and log flushing). > > > > I patched jbd's log_do_checkpoint to put all the blocks it wanted to > > write in a radix tree, then send them all down in order at the end. > > Side note: we already have all of that capability in the kernel: > sync_inode(blockdev_inode, wbc) will do an ascending-LBA write of the whole > blockdev. Why don't we simply plug the queue, do all the writes, and let the I/O scheduler sort it out instead? -- Mathematics is the supreme nostalgia of our time. - 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/