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 > 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 Hi Steve, I think I know why this is a problem and how to fix it, but I'm having a trouble reproducing this exact setup. Which of your tests was this oprofile from? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
