]> www.infradead.org Git - users/jedix/linux-maple.git/commit
Btrfs: stop using write_one_page
authorJosef Bacik <josef@redhat.com>
Mon, 26 Sep 2011 17:58:47 +0000 (13:58 -0400)
committerChris Mason <chris.mason@oracle.com>
Wed, 16 Nov 2011 02:20:25 +0000 (21:20 -0500)
commitfa0d7af219fe5ebe9b50fdd940d12d1ed33395a2
tree8147fa2b8b62f6d01770b7e65b4510218c11160a
parent5a6eb961686c0099690e1fb5ab9146c28e6202b4
Btrfs: stop using write_one_page

While looking for a performance regression a user was complaining about, I
noticed that we had a regression with the varmail test of filebench.  This was
introduced by

0d10ee2e6deb5c8409ae65b970846344897d5e4e

which keeps us from calling writepages in writepage.  This is a correct change,
however it happens to help the varmail test because we write out in larger
chunks.  This is largly to do with how we write out dirty pages for each
transaction.  If you run filebench with

load varmail
set $dir=/mnt/btrfs-test
run 60

prior to this patch you would get ~1420 ops/second, but with the patch you get
~1200 ops/second.  This is a 16% decrease.  So since we know the range of dirty
pages we want to write out, don't write out in one page chunks, write out in
ranges.  So to do this we call filemap_fdatawrite_range() on the range of bytes.
Then we convert the DIRTY extents to NEED_WAIT extents.  When we then call
btrfs_wait_marked_extents() we only have to filemap_fdatawait_range() on that
range and clear the NEED_WAIT extents.  This doesn't get us back to our original
speeds, but I've been seeing ~1380 ops/second, which is a <5% regression as
opposed to a >15% regression.  That is acceptable given that the original commit
greatly reduces our latency to begin with.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>
(cherry picked from commit 1728366efa5ebf48bd2ed544afa8700cd07ba822 with conflicts)
fs/btrfs/extent_io.h
fs/btrfs/transaction.c