From: Chris Mason <chris.mason@oracle.com>
To: Steven Pratt <steve@dangyankee.net>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 2.6.35 performance results
Date: Fri, 6 Aug 2010 14:58:35 -0400 [thread overview]
Message-ID: <20100806185835.GJ21412@think> (raw)
In-Reply-To: <4C5C57FB.4090003@dangyankee.net>
On Fri, Aug 06, 2010 at 01:44:11PM -0500, Steven Pratt wrote:
> Here is the latest set of performance runs from the 2.6.35-rc5 tree.
> Included is a refresh of all the other filesystems with some changes
> for barriers on and off since this has been somewhat of a hot topic
> recently.
>
> New data linked in to the history graphs here:
> http://btrfs.boxacle.net/repository/raid/history/History.html
>
> From a BTRFS performance perspective, we took a major regression on
> write heavy workloads. As much as a 10x hit! The problems seems to
> be due to this changeset:
> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
Ouch! The problem is we're not being aggressive enough about
allocating chunks for data, which makes the flusher come in and start
data IO.
Thanks a lot for finding the regression, my machine definitely didn't
show this.
I'll reproduce and fix it up.
-chris
> Btrfs: Shrink delay allocated space in a synchronized
>
> Shrink delayed allocation space in a synchronized manner is more
> controllable than flushing all delay allocated space in an async
> thread.
>
> This changeset introduced "btrfs_start_one_delalloc_inode" in
> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commitdiff;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
>
> In heavy write workloads this new function is now dominating the profiles:
>
> samples % app name symbol name
> 8914973 65.1261 btrfs.ko btrfs_start_one_delalloc_inode
> 1024841 7.4867 vmlinux-2.6.35-rc5-autokern1 rb_get_reader_page
> 716046 5.2309 vmlinux-2.6.35-rc5-autokern1 ring_buffer_consume
> 315354 2.3037 oprofile.ko add_event_entry
> 202484 1.4792 vmlinux-2.6.35-rc5-autokern1 write_inode_now
> 195018 1.4247 btrfs.ko btrfs_tree_lock
>
>
> Appears to be major contention on the spin lock, as this gets worse
> with more threads. This needs to be redone.
>
>
> Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-08-06 18:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 18:44 2.6.35 performance results Steven Pratt
2010-08-06 18:58 ` Chris Mason [this message]
2010-08-16 20:04 ` Chris Mason
2010-08-16 21:51 ` Steven Pratt
2010-08-19 1:00 ` Chris Mason
2010-08-21 15:25 ` Steven Pratt
2010-08-23 19:13 ` Steven Pratt
2010-08-23 19:33 ` Chris Mason
2010-08-23 20:10 ` Steven Pratt
-- strict thread matches above, loose matches on Subject: below --
2010-08-08 4:18 A. James Lewis
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=20100806185835.GJ21412@think \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=steve@dangyankee.net \
/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).