Subject: Re: yamt-readahead branch
To: None <tech-kern@netbsd.org>
From: Jed Davis <jdev@panix.com>
List: tech-kern
Date: 11/16/2005 20:34:49
Hubert Feyrer <feyrer@cs.stevens.edu> writes:

> On Tue, 15 Nov 2005, YAMAMOTO Takashi wrote:
>> a quick benchmark (bonnie++ -n0) is attached.
>> *1 and *2 are the same kernel.  i did the same test twice.
>> i'm wondering why "Rewrite" value has been changed.
>
> Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
>                      -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
[]
> readadead1     300M 10790  79 14023  79  8726  46 13632  80 20250  53  69.4 3
> readahead2     300M  8699  63 14001  79  8670  45 13474  80 19970  51  69.5 3

I found, a few months ago with bonnie (non-++), that I got strangely
variable numbers when using a softdep or async FFS in a Xen domU.
(Benchmarking from the dom0, or mounting sync -- I didn't think to try
the default behavior -- didn't have this problem.)  And I seem to
recall that having a program call fsync after writing and before
measuring the time (neither bonnie nor bonnie++ appear to use fsync)
would yield more consistent times.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))