From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Mason <chris.mason@fusionio.com>
Subject: Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL
 insertion during transaction commit [RFC])
Date: Mon, 8 Jul 2013 21:15:33 -0400
Message-ID: <20130709011533.3855.97802@localhost.localdomain>
References: <1372657476-9241-1-git-send-email-david@fromorbit.com>
 <20130708124453.GC3438@dastard>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8BIT
Cc: <linux-fsdevel@vger.kernel.org>
To: Dave Chinner <david@fromorbit.com>, <xfs@oss.sgi.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from dkim2.fusionio.com ([66.114.96.54]:54381 "EHLO
	dkim2.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751245Ab3GIBPf convert rfc822-to-8bit (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 8 Jul 2013 21:15:35 -0400
Received: from mx1.fusionio.com (unknown [10.101.1.160])
	by dkim2.fusionio.com (Postfix) with ESMTP id 92E209A069B
	for <linux-fsdevel@vger.kernel.org>; Mon,  8 Jul 2013 19:15:35 -0600 (MDT)
In-Reply-To: <20130708124453.GC3438@dastard>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Quoting Dave Chinner (2013-07-08 08:44:53)
> [cc fsdevel because after all the XFS stuff I did a some testing on
> mmotm w.r.t per-node LRU lock contention avoidance, and also some
> scalability tests against ext4 and btrfs for comparison on some new
> hardware. That bit ain't pretty. ]
> 
> And, well, the less said about btrfs unlinks the better:
> 
> +  37.14%  [kernel]  [k] _raw_spin_unlock_irqrestore
> +  33.18%  [kernel]  [k] __write_lock_failed
> +  17.96%  [kernel]  [k] __read_lock_failed
> +   1.35%  [kernel]  [k] _raw_spin_unlock_irq
> +   0.82%  [kernel]  [k] __do_softirq
> +   0.53%  [kernel]  [k] btrfs_tree_lock
> +   0.41%  [kernel]  [k] btrfs_tree_read_lock
> +   0.41%  [kernel]  [k] do_raw_read_lock
> +   0.39%  [kernel]  [k] do_raw_write_lock
> +   0.38%  [kernel]  [k] btrfs_clear_lock_blocking_rw
> +   0.37%  [kernel]  [k] free_extent_buffer
> +   0.36%  [kernel]  [k] btrfs_tree_read_unlock
> +   0.32%  [kernel]  [k] do_raw_write_unlock
> 

Hi Dave,

Thanks for doing these runs.  At least on Btrfs the best way to resolve
the tree locking today is to break things up into more subvolumes.  I've
got another run at the root lock contention in the queue after I get
the skiplists in place in a few other parts of the Btrfs code.

-chris