New XFS, ReiserFS and Ext2 benchmarks

New XFS, ReiserFS and Ext2 benchmarks

[Ricardo Galli]

Hi,
	you can find at http://bulma.lug.net/static/ a few new benchmarks among
Reiser, XFS and Ext2 (also one with JFS).

This time there is a comprehensive Hans' Mongo benchmarks
(http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
read/write/fsync operations tests (I was very careful of populating the
cache before the measures for the last two cases).

Regards,

--ricardo
http://m3d.uib.es/~gallir/

Re: New XFS, ReiserFS and Ext2 benchmarks

[Hans Reiser]

Ricardo Galli wrote:
> 
> Hi,
>         you can find at http://bulma.lug.net/static/ a few new benchmarks among
> Reiser, XFS and Ext2 (also one with JFS).
> 
> This time there is a comprehensive Hans' Mongo benchmarks
> (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
> read/write/fsync operations tests (I was very careful of populating the
> cache before the measures for the last two cases).
> 
> Regards,
> 
> --ricardo
> http://m3d.uib.es/~gallir/

These are interesting benchmarks, my only caveats are that make bzImage is
probably CPU bound not IO bound (the traditional value of compiles as FS
benchmarks does not apply to Linux filesystems, as they don't do the misdesigned
synchronization policy of older Unices, and compiles are CPU bound for them in
my experience), that I don't understand fully why we are so much faster at the
cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too
good to be true.

Thanks for investing the time into this Ricardo.

Hans

Re: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks

[Hans Reiser]

My apologies, I meant that the make is probably compiler bound (I said CPU
bound) not FS bound.

We find that one must use cp and similar utilities (not compilers) to become FS
bound when using a Linux FS (unlike the older Unixes for which compiles were
considered excellent benchmarks).

Hans Reiser wrote:

Hans
> 
> Ricardo Galli wrote:
> >
> > Hi,
> >         you can find at http://bulma.lug.net/static/ a few new benchmarks among
> > Reiser, XFS and Ext2 (also one with JFS).
> >
> > This time there is a comprehensive Hans' Mongo benchmarks
> > (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
> > read/write/fsync operations tests (I was very careful of populating the
> > cache before the measures for the last two cases).
> >
> > Regards,
> >
> > --ricardo
> > http://m3d.uib.es/~gallir/
> 
> These are interesting benchmarks, my only caveats are that make bzImage is
> probably CPU bound not IO bound (the traditional value of compiles as FS
> benchmarks does not apply to Linux filesystems, as they don't do the misdesigned
> synchronization policy of older Unices, and compiles are CPU bound for them in
> my experience), that I don't understand fully why we are so much faster at the
> cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too
> good to be true.
> 
> Thanks for investing the time into this Ricardo.
> 
> Hans

RE: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks

[Ricardo Galli]

> My apologies, I meant that the make is probably compiler bound (I said CPU
> bound) not FS bound.

We undertood ;-)

> > cp -ar, and I would like Yura to try to reproduce the cp -ar as
> >  it seems too
> > good to be true.
> We find that one must use cp and similar utilities (not

The cp -a figures are somehow interesting, I had to repeat it for evey file
system because the cache has to be populated before copying, to avoid the
influence of the file system where the kernel is copied from. I did it by
doing several cps before mesurements.

Despite my "efforts", variances were much higher en XFS than in ReiserFS and
Ext2. The ReiserFS individual times were closer to the average than the
other.

Why? have no idea, I didn't do any analysis of the samples because I am not
an expert in Statistics.


> compilers) to become FS
> bound when using a Linux FS (unlike the older Unixes for which
> compiles were
> considered excellent benchmarks).

I was equally suprised, not only due to the wall-clock time but also to the
CPU. So, I think the cache is the major player when compiling a kernel that
was _just_ copied from another file system (still in buffer/cache).

> > Thanks for investing the time into this Ricardo.

It's just for fun....

--ricardo

Re: New XFS, ReiserFS and Ext2 benchmarks

[Daniel Phillips]

On Tuesday 22 May 2001 04:41, Ricardo Galli wrote:
> Hi,
> 	you can find at http://bulma.lug.net/static/ a few new benchmarks
> among Reiser, XFS and Ext2 (also one with JFS).
>
> This time there is a comprehensive Hans' Mongo benchmarks
> (http://bulma.lug.net/static/mongo/ )and a couple of kernel
> compilations and read/write/fsync operations tests (I was very
> careful of populating the cache before the measures for the last two
> cases).

The measured create and rename times for Ext2 look pretty silly, don't they?
OK, I know that my htree directory index patch isn't part of Ext2 yet, but at 
least lets mention that this is a solved problem.

  http://nl.linux.org/~phillips/htree

--
Daniel

Re: New XFS, ReiserFS and Ext2 benchmarks

[Shawn]

Forbidden
You don't have permission to access /~phillips/htree on this server.


--------------------------------------------------------------------------------

Apache/1.3.14 Server at nl.linux.org Port 80

On 05/22, Daniel Phillips rearranged the electrons to read:
> On Tuesday 22 May 2001 04:41, Ricardo Galli wrote:
> > Hi,
> > 	you can find at http://bulma.lug.net/static/ a few new benchmarks
> > among Reiser, XFS and Ext2 (also one with JFS).
> >
> > This time there is a comprehensive Hans' Mongo benchmarks
> > (http://bulma.lug.net/static/mongo/ )and a couple of kernel
> > compilations and read/write/fsync operations tests (I was very
> > careful of populating the cache before the measures for the last two
> > cases).
> 
> The measured create and rename times for Ext2 look pretty silly, don't they?
> OK, I know that my htree directory index patch isn't part of Ext2 yet, but at 
> least lets mention that this is a solved problem.
> 
>   http://nl.linux.org/~phillips/htree
> 
> --
> Daniel
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
--
Hob Goblin
core@enodev.com

Truth is ever to be found in the simplicity, and not in the multiplicity and confusion of things. - Sir Isaac Newton (1642-1727)

Re: New XFS, ReiserFS and Ext2 benchmarks

[Daniel Phillips]

On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> The measured create and rename times for Ext2 look pretty silly,
> don't they? OK, I know that my htree directory index patch isn't part
> of Ext2 yet, but at least lets mention that this is a solved problem.
>
>   http://nl.linux.org/~phillips/htree

Oops, nl.linux.org was down for 'unscheduled maintainance' and seems
to have come back up with some some http issues.

Rik?

--
Daniel

Re: New XFS, ReiserFS and Ext2 benchmarks

[Rik van Riel]

On Tue, 22 May 2001, Daniel Phillips wrote:
> On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:

> >   http://nl.linux.org/~phillips/htree
> 
> Oops, nl.linux.org was down for 'unscheduled maintainance' and seems
> to have come back up with some some http issues.
> 
> Rik?

[/home]# chmod a+x *

Things seem to work again now ;)

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks

[Hans Reiser]

Ricardo Galli wrote:

> I was equally suprised, not only due to the wall-clock time but also to the
> CPU. So, I think the cache is the major player when compiling a kernel that
> was _just_ copied from another file system (still in buffer/cache).
You might consider rebooting to flush the cache.

Hans

RE: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks

[Ricardo Galli]

> > was _just_ copied from another file system (still in buffer/cache).
> You might consider rebooting to flush the cache.
> 


Is it possible to achieve the same by umounting/mounting the file system? 

--ricardo

Re: New XFS, ReiserFS and Ext2 benchmarks

[David N. Lombard]

Rik van Riel wrote:
> 
> On Tue, 22 May 2001, Daniel Phillips wrote:
> > On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> 
> > >   http://nl.linux.org/~phillips/htree
> >
> > Oops, nl.linux.org was down for 'unscheduled maintainance' and seems
> > to have come back up with some some http issues.
> >
> > Rik?
> 
> [/home]# chmod a+x *
> 
> Things seem to work again now ;)
> 

Not so much:

Forbidden

You don't have permission to access /~phillips/htree/ on this server.


Apache/1.3.14 Server at nl.linux.org Port 80

-- 
David N. Lombard

Re: New XFS, ReiserFS and Ext2 benchmarks

[Daniel Phillips]

On Tuesday 22 May 2001 20:20, David N. Lombard wrote:
> Rik van Riel wrote:
> > On Tue, 22 May 2001, Daniel Phillips wrote:
> > > On Tuesday 22 May 2001 12:29, Daniel Phillips wrote:
> > > >   http://nl.linux.org/~phillips/htree
> > >
> > > Oops, nl.linux.org was down for 'unscheduled maintainance' and
> > > seems to have come back up with some some http issues.
> > >
> > > Rik?
> >
> > [/home]# chmod a+x *
> >
> > Things seem to work again now ;)
>
> Not so much:
>
> Forbidden
>
> You don't have permission to access /~phillips/htree/ on this server.

This too was fixed.  You could access the individual files in that
directory, but not list the directory :-/  Last I heard, Rik had his head
down cleaning up some other administrative things on the new box.

The relevant URL's are:

   http://nl.linux.org/~phillips/htree/READ-ME
   http://nl.linux.org/~phillips/htree/dx.pcache-2.4.4-7
   ftp://ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz

Right now, the directory index patch is a patch on top of Al's patch,
sorry, we are in a state of transition. ;-)

--
Daniel