On Mon, 2008-11-03 at 13:14 -0600, Steven Pratt wrote: > Chris Mason wrote: > > On Wed, 2008-10-22 at 15:06 -0500, Steven Pratt wrote: > > > >> We have set up a new page which is intended mainly for tracking the > >> performance of BTRFS, but in doing so we are testing other filesystems > >> as well (ext3, ext4, xfs and jfs). Thought some people here might find > >> the results useful. > >> > > > > I think I understand the bad read performance in btrfs. I was forcing a > > tiny max readahead size. > > > > The current git tree has fixes for it, along with a ton of new code. > > > Results for the the new (Git pull on 10/29) on the raid system are > complete. Sequential read with a small number of threads has increased > dramatically, however on large number of threads (128) we see a large > dropoff in performance from before, as well as a huge spike in CPU > utilization. A quick look at the oprofile reveals some new functions at > the top which seem really out of place on a read only workload. > > samples % image name app name symbol > name > 13752215 23.8658 btrfs.ko btrfs > alloc_extent_state > 12840571 22.2837 btrfs.ko btrfs > free_extent_state
It took a while, but I think I've tracked this down. Btrfs has some debugging code to detect and cleanup leaks of the extent_state structs, and this adds a lot of contention to the alloc_extent_state and free_extent_state code. I've pushed out fixes for this, along with some other important optimizations that should improve btrfs scores in your benchmarks. Could you please give things a try? -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
