> 
> In my earlier message, I stated that I recognised no FreeBSD problems
> related to VM code. That was a bit too optimistic. There is a problem
> that a FreeBSD machine may lock up for a couple of seconds under
> certain circumstances, especially heavy use of buffer caches. I didn't
> encouter it myself, since I don't have a FreeBSD under heavy load, but
> as far as I understand, the problem will cause repeated lockups once
> it occurs and force (but not cause) a reboot of the machine. The
> problem was discussed on FreeBSD-current@freebsd.org some days ago.
> 
There are three seperate problems.  #1 is related to the large number of
inodes that sometimes need to be updated.  I think that the same problem
exists architecturally in 4.4Lite in general.  The read/modify/write of
the blocks where the inodes reside is one of the primary causes -- it
is a 4.4 artifact that I am working on right now, along with the 2GB
FreeBSD file size limit.  My latest test code run approx 2x faster using
the 'lat_fs' file removal benchmark for filesystems not mounted async.
(Approx 200per second on WD caviar 540 drives!!!)

#2 I think is related to an unfortunate kernel option that we have that
people use called 'AUTO_EOI_2' -- it is generally evil and the performance
gains are marginal.  That flag is 'for experts only'.  It can cause system
hangs and is not on by default.  I am still investigating.

#3 The FreeBSD disksort has an unfortunate policy associated with it -- that
has been fixed in -current.  (disksort is needed much less in FreeBSD since
the '94 timeframe anyway -- due to changes in some of the vfs code.)  The
policy has been changed to give priority to reads.

One more thing, is that the default buffer cache size on FreeBSD is about
twice that of NetBSD -- and that means that there can be more dirty blocks.
At least the size of the dirty buffer memory is limited -- some merged
schemes might allow even more.  That can make 'sync' time much worse
under certain circumstances.

I know of no major architectural flaws in the FreeBSD VM code -- but I am
listening, and am looking for improvements all of the time.  Nothing is perfect
until it has been used in the field for a while!!!


John
dyson@freebsd.org