Re: Desktop Filesystem Benchmarks in 2.6.3

From: Hans Reiser
Date: Wed Mar 03 2004 - 01:35:13 EST


Unfortunately it is a bit more complex, and the truth is less complementary to us than what you write. Reiser4's CPU usage has come down a lot, but it still consumes more CPU than V3. It should consume less, and Zam is currently working on making writes more CPU efficient. As soon as I get funding from somewhere and can stop worrying about money, I will do a complete code review, and CPU usage will go way down. There are always lots of stupid little things that consume a lot of CPU that I find whenever I stop chasing money and review code.

We are shipping because CPU usage is not as important as IO efficiency for a filesystem, and while Reiser4 is not as fast as it will be in 3-6 months, it is faster than anything else available so it should be shipped.

Hans

Dax Kelson wrote:

On Tue, 2004-03-02 at 09:34, Peter Nelson wrote:


Hans Reiser wrote:

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



My understanding (which could be completely wrong) is that reieserfs v3
and v4 are algorithmically more complex than ext2 or ext3. Reiserfs
spends more CPU time to make the eventual ondisk operations more
efficient/faster.

When operating purely or mostly out of ram, the higher CPU utilization
of reiserfs hurts performance compared to ext2 and ext3.

When your system I/O utilization exceeds cache size and your disks
starting getting busy, the CPU time previously invested by reiserfs pays
big dividends and provides large performance gains versus more
simplistic filesystems.

In other words, the CPU penalty paid by reiserfs v3/v4 is more than made
up for by the resultant more efficient disk operations. Reiserfs trades CPU for disk performance.

In a nutshell, if you have more memory than you know what do to with,
stick with ext3. If you spend all your time waiting for disk operations
to complete, go with reiserfs.

Dax Kelson
Guru Labs







--
Hans


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/