On Tue, May 22 2007, Matt Mackall wrote: > On Tue, May 22, 2007 at 11:21:20AM -0700, Andrew Morton wrote: > > On Tue, 22 May 2007 12:35:11 -0400 > > Chris Mason <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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?
The data set is too huge for that to work, even if you increased nr_requests to some huuuge number. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
