[Top] [All Lists]

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

To: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Subject: Re: Some baseline tests on new hardware (was Re: [PATCH] xfs: optimise CIL insertion during transaction commit [RFC])
From: Jan Kara <jack@xxxxxxx>
Date: Mon, 8 Jul 2013 17:38:07 +0200
Cc: Jan Kara <jack@xxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51DAD943.6050703@xxxxxxxxx>
References: <1372657476-9241-1-git-send-email-david@xxxxxxxxxxxxx> <20130708124453.GC3438@dastard> <20130708135953.GF5988@xxxxxxxxxxxxx> <51DAD943.6050703@xxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon 08-07-13 17:22:43, Marco Stornelli wrote:
> Il 08/07/2013 15:59, Jan Kara ha scritto:
> >On Mon 08-07-13 22:44:53, Dave Chinner wrote:
> ><snipped some nice XFS results ;)>
> >>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.
> >   Thanks for posting the numbers. There isn't anyone seriously testing ext4
> >SMP scalability AFAIK so it's not surprising it sucks.
> Funny, if I well remember Google guys switched android from yaffs2
> to ext4 due to its superiority on SMP :)
  Well, there's SMP and SMP. Ext4 is perfectly OK for desktop kind of SMP -
that's what lots of people use. When we speak of heavy IO load with 16 CPUs
on enterprise grade storage so that CPU (and not IO) bottlenecks are actually
visible, that's not so easily available and so we don't have serious
performance work in that direction...

Jan Kara <jack@xxxxxxx>

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