From owner-freebsd-hackers Fri Mar 6 19:14:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12371 for freebsd-hackers-outgoing; Fri, 6 Mar 1998 19:14:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12193 for ; Fri, 6 Mar 1998 19:13:42 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id WAA00262; Fri, 6 Mar 1998 22:13:34 -0500 (EST) (envelope-from toor) Message-Id: <199803070313.WAA00262@dyson.iquest.net> Subject: Re: VM/Buffer cache sizing... (e.g. for serving NFS) In-Reply-To: <199803070258.UAA06647@friley585.res.iastate.edu> from Chris Csanady at "Mar 6, 98 08:58:39 pm" To: ccsanady@iastate.edu Date: Fri, 6 Mar 1998 22:13:34 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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