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)))))