From: Nick Piggin <npiggin@kernel.dk>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Frank Mayhar <fmayhar@google.com>,
John Stultz <johnstul@us.ibm.com>
Subject: Re: VFS scalability git tree
Date: Tue, 27 Jul 2010 21:09:58 +1000 [thread overview]
Message-ID: <20100727110958.GA2913@amd> (raw)
In-Reply-To: <20100727070538.GA2893@amd>
On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote:
> On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote:
> > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote:
> > > I'm pleased to announce I have a git tree up of my vfs scalability work.
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
> > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git
> > >
> > > Branch vfs-scale-working
> >
> > With a production build (i.e. no lockdep, no xfs debug), I'll
> > run the same fs_mark parallel create/unlink workload to show
> > scalability as I ran here:
> >
> > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html
>
> I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead
> of a real disk (I don't have easy access to a good disk setup ATM, but
> I guess we're more interested in code above the block layer anyway).
>
> Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as
> yours.
I also tried dbench on this setup. 20 runs of dbench -t20 8
(that is a 20 second run, 8 clients).
Numbers are throughput, higher is better:
N Min Max Median Avg Stddev
vanilla 20 2219.19 2249.43 2230.43 2230.9915 7.2528893
scale 20 2428.21 2490.8 2437.86 2444.111 16.668256
Difference at 95.0% confidence
213.119 +/- 8.22695
9.55268% +/- 0.368757%
(Student's t, pooled s = 12.8537)
vfs-scale is 9.5% or 210MB/s faster than vanilla.
Like fs_mark, dbench has creat/unlink activity, so I hope rcu-inodes
should not be such a problem in practice. In my creat/unlink benchmark,
it is creating and destroying one inode repeatedly, which is the
absolute worst case for rcu-inodes. Wheras in most real workloads
would be creating and destroying many inodes, which is not such a dis
advantage for rcu-inodes.
Incidentally, XFS was by far the fastest "real" filesystem I tested on
this workload. ext4 was around 1700MB/s (ext2 was around 3100MB/s and
ramfs is 3350MB/s).
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@kernel.dk>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Dave Chinner <david@fromorbit.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Frank Mayhar <fmayhar@google.com>,
John Stultz <johnstul@us.ibm.com>
Subject: Re: VFS scalability git tree
Date: Tue, 27 Jul 2010 21:09:58 +1000 [thread overview]
Message-ID: <20100727110958.GA2913@amd> (raw)
In-Reply-To: <20100727070538.GA2893@amd>
On Tue, Jul 27, 2010 at 05:05:39PM +1000, Nick Piggin wrote:
> On Fri, Jul 23, 2010 at 11:55:14PM +1000, Dave Chinner wrote:
> > On Fri, Jul 23, 2010 at 05:01:00AM +1000, Nick Piggin wrote:
> > > I'm pleased to announce I have a git tree up of my vfs scalability work.
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
> > > http://git.kernel.org/?p=linux/kernel/git/npiggin/linux-npiggin.git
> > >
> > > Branch vfs-scale-working
> >
> > With a production build (i.e. no lockdep, no xfs debug), I'll
> > run the same fs_mark parallel create/unlink workload to show
> > scalability as I ran here:
> >
> > http://oss.sgi.com/archives/xfs/2010-05/msg00329.html
>
> I've made a similar setup, 2s8c machine, but using 2GB ramdisk instead
> of a real disk (I don't have easy access to a good disk setup ATM, but
> I guess we're more interested in code above the block layer anyway).
>
> Made an XFS on /dev/ram0 with 16 ags, 64MB log, otherwise same config as
> yours.
I also tried dbench on this setup. 20 runs of dbench -t20 8
(that is a 20 second run, 8 clients).
Numbers are throughput, higher is better:
N Min Max Median Avg Stddev
vanilla 20 2219.19 2249.43 2230.43 2230.9915 7.2528893
scale 20 2428.21 2490.8 2437.86 2444.111 16.668256
Difference at 95.0% confidence
213.119 +/- 8.22695
9.55268% +/- 0.368757%
(Student's t, pooled s = 12.8537)
vfs-scale is 9.5% or 210MB/s faster than vanilla.
Like fs_mark, dbench has creat/unlink activity, so I hope rcu-inodes
should not be such a problem in practice. In my creat/unlink benchmark,
it is creating and destroying one inode repeatedly, which is the
absolute worst case for rcu-inodes. Wheras in most real workloads
would be creating and destroying many inodes, which is not such a dis
advantage for rcu-inodes.
Incidentally, XFS was by far the fastest "real" filesystem I tested on
this workload. ext4 was around 1700MB/s (ext2 was around 3100MB/s and
ramfs is 3350MB/s).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-07-27 11:10 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 19:01 VFS scalability git tree Nick Piggin
2010-07-22 19:01 ` Nick Piggin
2010-07-23 11:13 ` Dave Chinner
2010-07-23 11:13 ` Dave Chinner
2010-07-23 14:04 ` [PATCH 0/2] vfs scalability tree fixes Dave Chinner
2010-07-23 14:04 ` Dave Chinner
2010-07-23 16:09 ` Nick Piggin
2010-07-23 16:09 ` Nick Piggin
2010-07-23 14:04 ` [PATCH 1/2] xfs: fix shrinker build Dave Chinner
2010-07-23 14:04 ` Dave Chinner
2010-07-23 14:04 ` [PATCH 2/2] xfs: shrinker should use a per-filesystem scan count Dave Chinner
2010-07-23 14:04 ` Dave Chinner
2010-07-23 15:51 ` VFS scalability git tree Nick Piggin
2010-07-23 15:51 ` Nick Piggin
2010-07-24 0:21 ` Dave Chinner
2010-07-24 0:21 ` Dave Chinner
2010-07-23 11:17 ` Christoph Hellwig
2010-07-23 11:17 ` Christoph Hellwig
2010-07-23 15:42 ` Nick Piggin
2010-07-23 15:42 ` Nick Piggin
2010-07-23 13:55 ` Dave Chinner
2010-07-23 13:55 ` Dave Chinner
2010-07-23 16:16 ` Nick Piggin
2010-07-23 16:16 ` Nick Piggin
2010-07-27 7:05 ` Nick Piggin
2010-07-27 7:05 ` Nick Piggin
2010-07-27 8:06 ` Nick Piggin
2010-07-27 8:06 ` Nick Piggin
2010-07-27 11:36 ` XFS hang in xlog_grant_log_space (was Re: VFS scalability git tree) Nick Piggin
2010-07-27 13:30 ` Dave Chinner
2010-07-27 14:58 ` XFS hang in xlog_grant_log_space Dave Chinner
2010-07-28 13:17 ` Dave Chinner
2010-07-29 14:05 ` Nick Piggin
2010-07-29 22:56 ` Dave Chinner
2010-07-30 3:59 ` Nick Piggin
2010-07-28 12:57 ` VFS scalability git tree Dave Chinner
2010-07-28 12:57 ` Dave Chinner
2010-07-29 14:03 ` Nick Piggin
2010-07-29 14:03 ` Nick Piggin
2010-07-27 11:09 ` Nick Piggin [this message]
2010-07-27 11:09 ` Nick Piggin
2010-07-27 13:18 ` Dave Chinner
2010-07-27 13:18 ` Dave Chinner
2010-07-27 15:09 ` Nick Piggin
2010-07-27 15:09 ` Nick Piggin
2010-07-28 4:59 ` Dave Chinner
2010-07-28 4:59 ` Dave Chinner
2010-07-28 4:59 ` Dave Chinner
2010-07-23 15:35 ` Nick Piggin
2010-07-23 15:35 ` Nick Piggin
2010-07-24 8:43 ` KOSAKI Motohiro
2010-07-24 8:43 ` KOSAKI Motohiro
2010-07-24 8:44 ` [PATCH 1/2] vmscan: shrink_all_slab() use reclaim_state instead the return value of shrink_slab() KOSAKI Motohiro
2010-07-24 8:44 ` KOSAKI Motohiro
2010-07-24 8:44 ` KOSAKI Motohiro
2010-07-24 12:05 ` KOSAKI Motohiro
2010-07-24 12:05 ` KOSAKI Motohiro
2010-07-24 8:46 ` [PATCH 2/2] vmscan: change shrink_slab() return tyep with void KOSAKI Motohiro
2010-07-24 8:46 ` KOSAKI Motohiro
2010-07-24 8:46 ` KOSAKI Motohiro
2010-07-24 10:54 ` VFS scalability git tree KOSAKI Motohiro
2010-07-24 10:54 ` KOSAKI Motohiro
2010-07-26 5:41 ` Nick Piggin
2010-07-26 5:41 ` Nick Piggin
2010-07-28 10:24 ` Nick Piggin
2010-07-28 10:24 ` Nick Piggin
2010-07-30 9:12 ` Nick Piggin
2010-07-30 9:12 ` Nick Piggin
2010-08-03 0:27 ` john stultz
2010-08-03 0:27 ` john stultz
2010-08-03 0:27 ` john stultz
2010-08-03 5:44 ` Nick Piggin
2010-08-03 5:44 ` Nick Piggin
2010-08-03 5:44 ` Nick Piggin
2010-09-14 22:26 ` Christoph Hellwig
2010-09-14 23:02 ` Frank Mayhar
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=20100727110958.GA2913@amd \
--to=npiggin@kernel.dk \
--cc=david@fromorbit.com \
--cc=fmayhar@google.com \
--cc=johnstul@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.