From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org
Subject: Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC])
Date: Tue, 9 Jul 2013 11:23:44 +1000 [thread overview]
Message-ID: <20130709012344.GG3438@dastard> (raw)
In-Reply-To: <20130709004332.GB23174@gmail.com>
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@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org
Subject: Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC])
Date: Tue, 9 Jul 2013 11:23:44 +1000 [thread overview]
Message-ID: <20130709012344.GG3438@dastard> (raw)
In-Reply-To: <20130709004332.GB23174@gmail.com>
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@fromorbit.com
next prev parent reply other threads:[~2013-07-09 1:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 5:44 [PATCH] xfs: optimise CIL insertion during transaction commit [RFC] Dave Chinner
2013-07-04 2:09 ` Mark Tinguely
2013-07-08 12:44 ` Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC]) Dave Chinner
2013-07-08 12:44 ` Dave Chinner
2013-07-08 13:59 ` Jan Kara
2013-07-08 15:22 ` Marco Stornelli
2013-07-08 15:22 ` Marco Stornelli
2013-07-08 15:38 ` Jan Kara
2013-07-09 0:15 ` Dave Chinner
2013-07-09 0:15 ` Dave Chinner
2013-07-09 0:56 ` Theodore Ts'o
2013-07-09 0:56 ` Theodore Ts'o
2013-07-09 0:43 ` Zheng Liu
2013-07-09 0:43 ` Zheng Liu
2013-07-09 1:23 ` Dave Chinner [this message]
2013-07-09 1:23 ` Dave Chinner
2013-07-09 1:15 ` Chris Mason
2013-07-09 1:15 ` Chris Mason
2013-07-09 1:26 ` Dave Chinner
2013-07-09 1:54 ` [BULK] " Chris Mason
2013-07-09 1:54 ` Chris Mason
2013-07-09 8:26 ` Dave Chinner
2013-07-09 8:26 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130709012344.GG3438@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.