From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: File System Performance results Date: Mon, 10 Nov 2008 13:11:57 -0500 Message-ID: <1226340717.23781.18.camel@think.oraclecorp.com> References: <48FF87CE.2090502@austin.ibm.com> <1225308408.6448.287.camel@think.oraclecorp.com> <490F4D98.2050608@austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Cc: linux-btrfs@vger.kernel.org To: Steven Pratt Return-path: In-Reply-To: <490F4D98.2050608@austin.ibm.com> List-ID: 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