Subject: Re: mfs changes [thorpej@netbsd.org: CVS commit: syssrc]
To: None <thorpej@netbsd.org>
From: Simon Burge <simonb@netbsd.org>
List: tech-kern
Date: 05/23/2000 11:22:52
Simon Burge wrote:

> Jason R Thorpe wrote:
> 
> > Redo the way MFS does I/O to the server's address space.  Instead of
> > queueing up buffers and awakening the MFS server process to do the I/O,
> > we do the I/O to the server process's address space directly using
> > facilities provided by UVM.
> 
> Way cool!  Do you have any figures to show if mfs is faster because of
> these changes?  It should at least reduce the context switch overhead...

Almost a moot point now, but I did get some bonnie figures before you
reverted the change.  This is on a PC164 with 128MB of RAM and a 64MB
mfs /tmp.  "omfs" is the original mfs, "nmfs" is your new (old?!) mfs.

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
alpha:omfs 20 12328 75.8 25606 64.2 19728 59.2 12468 74.1 28846 40.5 4380.7 42.9
alpha:omfs 20 11453 83.5 26346 62.9 17418 47.4 12192 74.5 29831 36.7 4316.1 43.9
alpha:omfs 20 11942 83.0 28807 60.1 20126 38.2 12483 74.3 33825 29.5 4423.3 42.8
alpha:omfs 50 11495 79.9 28127 59.9 22434 45.8 12379 74.0 34044 28.8 3904.6 35.1
alpha:omfs 50 11763 83.0 26586 61.7 21183 47.3 12333 73.7 33890 28.2 3882.5 37.1
alpha:omfs 50 11899 82.6 28886 58.5 24317 44.8 12432 74.1 34289 28.2 3676.9 43.5

alpha:nmfs 20 11644 100. 25955 100. 19953 100. 11861 100. 28037 100. 3713.5 99.7
alpha:nmfs 20 11729 100. 27777 99.9 18825 100. 12171 100. 32363 100. 3806.7 99.5
alpha:nmfs 20 11586 100. 26647 100. 18641 100. 12157 100. 31775 100. 3803.2 99.7
alpha:nmfs 50 11250 100. 26627 99.9 20480 100. 12094 100. 29993 100. 3349.2 99.8
alpha:nmfs 50 11750 100. 27754 99.7 22338 100. 12074 100. 32165 100. 3319.3 99.8
alpha:nmfs 50 10979 100. 27550 100. 21727 100. 12013 100. 31910 100. 3192.5 99.8

Interesting how if anything there's a slight decrease in performance.
The full CPU utilitisation is obviously because there's no context
switch overhead at all...  I hand edited the "100." bits - bonnie didn't
cater for "100.0" in the %CPU columns :-)

Simon.