|To:||Hans Reiser <reiser@xxxxxxxxxxx>|
|Subject:||Re: Desktop Filesystem Benchmarks in 2.6.3|
|From:||Peter Nelson <pnelson@xxxxxxxxxxxxxx>|
|Date:||Tue, 02 Mar 2004 11:34:15 -0500|
|Cc:||linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, ext2-devel@xxxxxxxxxxxxxxxxxxxxx, ext3-users@xxxxxxxxxx, jfs-discussion@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx, reiserfs-list@xxxxxxxxxxx, linux-xfs@xxxxxxxxxxx|
|User-agent:||Mozilla Thunderbird 0.5 (X11/20040221)|
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`.
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|