xfs
[Top] [All Lists]

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

To: xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
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:23:44 +1000
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130709004332.GB23174@xxxxxxxxx>
References: <1372657476-9241-1-git-send-email-david@xxxxxxxxxxxxx> <20130708124453.GC3438@dastard> <20130709004332.GB23174@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jul 09, 2013 at 08:43:32AM +0800, Zheng Liu wrote:
> Hi Dave,
> 
> On Mon, Jul 08, 2013 at 10:44:53PM +1000, Dave Chinner wrote:
> [...]
> > So, lets look at ext4 vs btrfs vs XFS at 16-way (this is on the
> > 3.10-cil kernel I've been testing XFS on):
> > 
> >         create               walk           unlink
> >      time(s)   rate         time(s)         time(s)
> > xfs   222   266k+-32k         170             295
> > ext4          978    54k+- 2k         325            2053
> > btrfs        1223    47k+- 8k         366           12000(*)
> > 
> > (*) Estimate based on a removal rate of 18.5 minutes for the first
> > 4.8 million inodes.
> > 
> > Basically, neither btrfs or ext4 have any concurrency scaling to
> > demonstrate, and unlinks on btrfs a just plain woeful.
> > 
> > ext4 create rate is limited by the extent cache LRU locking:
> 
> I have a patch to fix this problem and the patch has been applied into
> 3.11-rc1.  The patch is (d3922a77):
>   ext4: improve extent cache shrink mechanism to avoid to burn CPU time
> 
> I do really appreicate that if you could try your testing again against
> this patch.  I just want to make sure that this problem has been fixed.
> At least in my own testing it looks fine.

I'll redo them when 3.11-rc1 comes around. I'll let you know how
much better it is, and where the next ring of the onion lies.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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