On Sun, Aug 30, 2009 at 02:17:31PM -0400, Theodore Tso wrote:
[ ... ]

Jens?  What do you think?  Fixing MAX_WRITEBACK_PAGES was something I
really wanted to merge in 2.6.32 since it makes a huge difference for
the block allocation layout for a "rsync -avH /old-fs /new-fs" when we
are copying bunch of large files (say, 800 meg iso images) and so the
fact that the writeback routine is writing out 4 megs at a time, means
that our files get horribly interleaved and thus get fragmented.

I did some runs comparing mainline with Jens' current writeback queue.
This is just btrfs, but its a good example of how things are improving.

These graphs show us the 'compile' phase of compilebench, where it is
writing all the .o files into the 30 kernel trees.  Basically we have
one thread, creating a bunch of files based on the sizes of all the .o
files in a compiled kernel.  They are created in random order, similar
to the files produced from a make -j.

I haven't yet tried this without the max_writeback_pages patch, but the
graphs clearly show a speed improvement, and that the mainline code is
smearing writes across the drive while Jens' work is writing
sequentially.

Jens' writeback branch:
http://oss.oracle.com/~mason/seekwatcher/compilebench-writes-axboe.png

Mainline
http://oss.oracle.com/~mason/seekwatcher/compilebench-writes-pdflush.png

-chris

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>