From: Miao Xie <miaox@cn.fujitsu.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH V2 4/4] Btrfs: flush the dirty pages of the ordered extent aggressively during logging csum
Date: Tue, 14 Jan 2014 20:31:52 +0800 [thread overview]
Message-ID: <1389702712-26638-5-git-send-email-miaox@cn.fujitsu.com> (raw)
In-Reply-To: <1389702712-26638-1-git-send-email-miaox@cn.fujitsu.com>
The performance of fsync dropped down suddenly sometimes, the main reason
of this problem was that we might only flush part dirty pages in a ordered
extent, then got that ordered extent, wait for the csum calcucation. But if
no task flushed the left part, we would wait until the flusher flushed them,
sometimes we need wait for several seconds, it made the performance drop
down suddenly. (On my box, it drop down from 56MB/s to 4-10MB/s)
This patch improves the above problem by flushing left dirty pages aggressively.
Test Environment:
CPU: 2CPU * 2Cores
Memory: 4GB
Partition: 20GB(HDD)
Test Command:
# sysbench --num-threads=8 --test=fileio --file-num=1 \
> --file-total-size=8G --file-block-size=32768 \
> --file-io-mode=sync --file-fsync-freq=100 \
> --file-fsync-end=no --max-requests=10000 \
> --file-test-mode=rndwr run
Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
---
fs/btrfs/tree-log.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 251e6f4..944701b 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3470,7 +3470,11 @@ static int log_one_extent(struct btrfs_trans_handle *trans,
&ordered->flags))
continue;
- wait_event(ordered->wait, ordered->csum_bytes_left == 0);
+ if (ordered->csum_bytes_left) {
+ btrfs_start_ordered_extent(inode, ordered, 0);
+ wait_event(ordered->wait,
+ ordered->csum_bytes_left == 0);
+ }
list_for_each_entry(sum, &ordered->list, list) {
ret = btrfs_csum_file_blocks(trans, log, sum);
--
1.7.1
prev parent reply other threads:[~2014-01-14 13:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 12:31 [PATCH V2 0/4] Btrfs: improve the performance fluctuating of the fsync Miao Xie
2014-01-14 12:31 ` [PATCH V2 1/4] Btrfs: filter the ordered extents that has been logged Miao Xie
2014-01-28 14:50 ` Josef Bacik
2014-01-29 2:08 ` Miao Xie
2014-01-14 12:31 ` [PATCH V2 2/4] Btrfs: don't get the lock when adding a csum into a ordered extent Miao Xie
2014-01-28 16:00 ` Josef Bacik
2014-01-29 2:25 ` Miao Xie
2014-01-29 18:43 ` Josef Bacik
2014-01-14 12:31 ` [PATCH V2 3/4] Btrfs: don't mix the ordered extents of all files together during logging the inodes Miao Xie
2014-01-28 14:55 ` Josef Bacik
2014-01-29 2:22 ` Miao Xie
2014-01-29 18:48 ` Josef Bacik
2014-01-14 12:31 ` Miao Xie [this message]
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=1389702712-26638-5-git-send-email-miaox@cn.fujitsu.com \
--to=miaox@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
/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).