Subject: Re: ffs and bufcache benchmarks - round two
To: Chuck Silvers <chuq@chuq.com>
From: None <mauzi@expertlan.hu>
List: tech-perform
Date: 09/23/2001 12:22:20
> for NetBSD-1.5Y, the second run has the whole file still in memory,
> so copying that out to the disk is very fast.  keeping the whole file
> in memory is great for this benchmark, but there are other situations
> where it's not so great, so this will probably change.

I agree that's not so great. Running disk-intensive tasks will eat up
all available memory, and then processes have to wait to the disks while
flushing the large caches. I had a terrible experience with Linux about 3
years ago - removing some memory from the machine improved the system
performance drastically! It's fixed there (in Linux) now.

I really loved the idea setting BUFCACHE (or BUFPAGES) to a fixed size.

Note: on NetBSD-1.5X after few hours of testing, malloc()ing about 32 megs
of memory failed with ENOMEM. the system had 256 megs of memory (eaten up
by the bufcache) I can try to reproduce this if you want.

> the more important question I have is:  why does it take
> NetBSD almost 4 times longer to read the file from disk?
> (ie. each of the first runs.)  were the source and destination
> filesystems on different physical disks or the same one?
> did you wipe the disk(s) and start from scratch for each OS,
> or do something else like installing all three on the same disk?
> did you lay out the partitions the same way for each OS?

The source and destination disk was the same. the tests were done on a
separate partition, the same with all the three different OS'es.

The problem is NetBSD seeks the disk about four times more than FreeBSD!
(and Linux) It seems like other OS'es are re-blocking data for
reading/writing using the disk bufcache.

Look at these test results:

FreeBSD 4.3-RC5, disk-to-disk copy of 64MB

- blocksize=512 bytes -> 8.8 sec
- blocksize=16 kbytes -> 8.4 sec

NetBSD 1.5Y, disk-to-disk copy of 64MB

- blocksize=512 bytes -> 42.6 sec
- blocksize=16 kbytes -> 8.9 sec

And these results are when we speak about ``first run''!

--
Gergely EGERVARY
System Administrator
Business Polytechnic, HUNGARY