From: Chris Mason <chris.mason@oracle.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-mm@kvack.org,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: [PATCH, RFC] vm: Add an tuning knob for vm.max_writeback_pages
Date: Tue, 1 Sep 2009 14:00:52 -0400 [thread overview]
Message-ID: <20090901180052.GA7885@think> (raw)
In-Reply-To: <20090830181731.GA20822@mit.edu>
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>
next prev parent reply other threads:[~2009-09-01 18:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1251600858-21294-1-git-send-email-tytso@mit.edu>
2009-08-30 16:52 ` [PATCH, RFC] vm: Add an tuning knob for vm.max_writeback_pages Christoph Hellwig
2009-08-30 18:17 ` Theodore Tso
2009-08-30 22:27 ` Christoph Hellwig
2009-08-31 3:08 ` Theodore Tso
2009-08-31 10:29 ` Jens Axboe
2009-08-31 10:47 ` Jens Axboe
2009-08-31 12:37 ` Theodore Tso
2009-08-31 15:54 ` Theodore Tso
2009-08-31 20:36 ` Jens Axboe
2009-08-31 21:03 ` Theodore Tso
2009-09-01 7:57 ` Aneesh Kumar K.V
2009-09-01 9:17 ` Jens Axboe
2009-09-01 18:00 ` Chris Mason [this message]
2009-09-01 20:30 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090901180052.GA7885@think \
--to=chris.mason@oracle.com \
--cc=hch@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).