xfs
[Top] [All Lists]

Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise C

To: Chris Mason <chris.mason@xxxxxxxxxxxx>
Subject: Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC])
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 9 Jul 2013 11:26:14 +1000
Cc: xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130709011533.3855.97802@xxxxxxxxxxxxxxxxxxxxx>
References: <1372657476-9241-1-git-send-email-david@xxxxxxxxxxxxx> <20130708124453.GC3438@dastard> <20130709011533.3855.97802@xxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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....

> 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 ;)

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>