Re: Filesystem benchmarks on reasonably fast hardware

[Dave Chinner <david@fromorbit.com>]

On Mon, Jul 18, 2011 at 01:40:36PM +0200, Jörn Engel wrote:
> On Mon, 18 July 2011 20:57:49 +1000, Dave Chinner wrote:
> > On Mon, Jul 18, 2011 at 09:53:39AM +0200, Jörn Engel wrote:
> > > On Mon, 18 July 2011 09:32:52 +1000, Dave Chinner wrote:
> > > > On Sun, Jul 17, 2011 at 06:05:01PM +0200, Jörn Engel wrote:
> > 
> > > > > xfs:
> > > > > ====
> > > > > seqrd	1	2	4	8	16	32	64	128
> > > > > 16384	4698	4424	4397	4402	4394	4398	4642	4679	
> > > > > 8192	6234	5827	5797	5801	5795	6114	5793	5812	
> > > > > 4096	9100	8835	8882	8896	8874	8890	8910	8906	
> > > > > 2048	14922	14391	14259	14248	14264	14264	14269	14273	
> > > > > 1024	23853	22690	22329	22362	22338	22277	22240	22301	
> > > > > 512	37353	33990	33292	33332	33306	33296	33224	33271	
> 
> Your patch definitely helps.  Bottom right number is 584741 now.
> Still slower than ext4 or btrfs, but in the right ballpark.  Will
> post the entire block once it has been generated.

The btrfs numbers are through doing different IO. have a look at all
the sub-filesystem block size numbers for btrfs. No matter the
thread count, the number is the same - hardware limits. btrfs is not
doing an IO per read syscall there - I'd say it's falling back to
buffered IO unlink ext4 and xfs....

.....

> seqrd	1	2	4	8	16	32	64	128
> 16384	4542	8311	15738	28955	38273	36644	38530	38527	
> 8192	6000	10413	19208	33878	65927	76906	77083	77102	
> 4096	8931	14971	24794	44223	83512	144867	147581	150702	
> 2048	14375	23489	34364	56887	103053	192662	307167	309222	
> 1024	21647	36022	49649	77163	132886	243296	421389	497581	
> 512	31832	61257	79545	108782	176341	303836	517814	584741	
> 
> Quite a nice improvement for such a small patch.  As they say, "every
> small factor of 17 helps". ;)

And in general the numbers are within a couple of percent of the
ext4 numbers, which is probably a reflection of the slightly higher
CPU cost of the XFS read path compared to ext4.

> What bothers me a bit is that the single-threaded numbers took such a
> noticeable hit...

Is it reproducable? I did notice quite a bit of run-to-run variation
in the numbers I ran. For single threaded numbers, they appear to be
in the order of +/-100 ops @ 16k block size.

> 
> > Ok, the patch below takes the numbers on my test setup on a 16k IO
> > size:
> > 
> > seqrd	1	2	4	8	16
> > vanilla	3603	2798	 2563	not tested...
> > patches 3707	5746	10304	12875	11016
> 
> ...in particular when your numbers improve even for a single thread.
> Wonder what's going on here.

And these were just quoted from a single test run.

> Anyway, feel free to add a Tested-By: or something from me.  And maybe
> fix the two typos below.

Will do.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html