lkml.org 
[lkml]   [2004]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Desktop Filesystem Benchmarks in 2.6.3
Hans Reiser wrote:

> Are you sure your benchmark is large enough to not fit into memory,
> particularly the first stages of it? It looks like not. reiser4 is
> much faster on tasks like untarring enough files to not fit into ram,
> but (despite your words) your results seem to show us as slower unless
> I misread them....

I'm pretty sure most of the benchmarking I am doing fits into ram,
particularly because my system has 1GB of it, but I see this as
realistic. When I download a bunch of debs (or rpms or the kernel) I'm
probably going to install them directly with them still in the file
cache. Same with rebuilding the kernel after working on it.

For untarring reiser4 is the fastest other than ext2. A somewhat less
ambiguous conclusion:

* Reiser4 is exceptionally fast at copying the system and the
fastest other than Ext2 at untaring, but is very slow at the
real-world debootstrap and kernel compiles.

> Reiser4 performs best on benchmarks that use the disk drive, and we
> usually only run benchmarks that use the disk drive.

I'm confused as to why performing a benchmark out of cache as opposed to
on disk would hurt performance?

> Here is summary of the results based upon what I am calling "dead"
> time calculated as `total time - user time`.
>
> You should be able to script out the user time.

I'm working with a friend of mine here at CMU doing hard drive research
to create a execution trace and test that directly instead of performing
all of the script actions.

-Peter Nelson
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.093 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site