Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Mar 1998 22:13:34 -0500 (EST)
From:      "John S. Dyson" <dyson@FreeBSD.ORG>
To:        ccsanady@iastate.edu
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: VM/Buffer cache sizing... (e.g. for serving NFS)
Message-ID:  <199803070313.WAA00262@dyson.iquest.net>
In-Reply-To: <199803070258.UAA06647@friley585.res.iastate.edu> from Chris Csanady at "Mar 6, 98 08:58:39 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Chris Csanady said:
>
> I had some questions about the workings of the buffer cache in our
> VM system.  Currently, it seems that although the size of the
> cache varies dynamically, the maximum is still preset at compile
> time.  Is this accurate?
>
There are two kinds of caching in FreeBSD, (write-back) and
(write-through, read) caching.  Note that the write-back caching
is limited to a reasonable size (to keep the disk from being
overwhelmed by pending write requests), but the other cache
is all of memory (including .text and mmapped files.)  The two
caches are physically the same and totally coherent, but logically
slightly different.  FreeBSD will not sandbag your disk subsystem
with pending write requests.  This design keeps the 'sync' command
from freezing your system :-).

> 
> The reason I ask, is that in linux, it seems to grow dynamically
> until it reaches near the limit of your physical memory.  I'm
> not sure how exactly it works, but can something similar be done
> it FreeBSD?  If the limit were to be set really high though,
> would it starve everything else?
>
FreeBSD does the same thing, but slightly more intelligently to
avoid such starving.  The algorithms are not complex, but are
also not intuitive.

> 
> When serving NFS to a large set of machines, it would allow for
> the entire file set to remain in cache (at least in our case,
> with 512M of ram.)  Is this type of thing possible?
> 
Of course :-).

To verify that it works on FreeBSD, try running iozone for nearly
the size of memory.  You'll find the the read performance is very
high up till some epsilon less than the size of available mem.

The performance problem that you might see is that our metadata
I/O is more conservative and not wide-open, unlike Linux.  You
can enable async metadata on UFS filesystems in order to get
similar filesystem consistancy issues like Linux.  The ONLY way
that I would enable async metadata on a production, multi-user
server is if there is a UPS on the system.  Even then, it requires
careful consideration.

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803070313.WAA00262>