From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: [BULK] Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC]) Date: Mon, 8 Jul 2013 21:54:19 -0400 Message-ID: <20130709015419.3855.98373@localhost.localdomain> References: <1372657476-9241-1-git-send-email-david@fromorbit.com> <20130708124453.GC3438@dastard> <20130709011533.3855.97802@localhost.localdomain> <20130709012614.GH3438@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Cc: , To: Dave Chinner Return-path: Received: from dkim1.fusionio.com ([66.114.96.53]:45243 "EHLO dkim1.fusionio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751736Ab3GIByW convert rfc822-to-8bit (ORCPT ); Mon, 8 Jul 2013 21:54:22 -0400 Received: from mx2.fusionio.com (unknown [10.101.1.160]) by dkim1.fusionio.com (Postfix) with ESMTP id F247C7C06A5 for ; Mon, 8 Jul 2013 19:54:21 -0600 (MDT) In-Reply-To: <20130709012614.GH3438@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Quoting Dave Chinner (2013-07-08 21:26:14) > On Mon, Jul 08, 2013 at 09:15:33PM -0400, Chris Mason wrote: > > 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. > > Sure, but you can't do that most workloads. Only on specialised > workloads (e.g. hashed directory tree based object stores) is this > really a viable option.... Yes and no. It makes a huge difference even when you have 8 procs all working on the same 8 subvolumes. It's not perfect but it's all I have ;) > > > 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. > > It will be interesting to see how these new structures play out ;) The skiplists don't translate well to the tree roots, so I'll probably have to do something different there. But I'll get the onion peeled one way or another. -chris