Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bruce.cs.monash.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!cs.utexas.edu!swrinde!pipex!uunet!ncrgw2.ncr.com!ncrhub2!ncrcae!news
From: john dyson <dyson@root.com>
Subject: Re: three questions about *BSD
Message-ID: <D1MsrL.LxL@ncrcae.ColumbiaSC.NCR.COM>
Sender: news@ncrcae.ColumbiaSC.NCR.COM (news)
Reply-To: dyson@root.com
Organization: Company, Address
X-Newsreader: DiscussIT for Windows (1.8.6) [Software Products Division of AT&T/NCR]
References: <T4TVBQWQ@math.fu-berlin.de>
Date: Fri, 30 Dec 1994 16:06:57 GMT
Lines: 74
>In article <T4TVBQWQ@math.fu-berlin.de> Thomas Graichen writes:
>hello again
>
>here are also three question about i think all (Free) *BSD's:
>
>* how can i change the number of allocated buffers at bootup time (maybe in
>the kernel sources) because i think (namely FreeBSD) takes about 20% of the
>memory for buffers ?
>
You can re-compile the kernel and specify more buffers if you want on
FreeBSD V1.X and V2.0.
>* is anybody working on a linux-like buffer concept for *BSD (using most of
>the actual free memory as buffers) - or is it still included in the latest
>versions ?
FreeBSD V2.1 will definitely have the merged VM/Buffer cache scheme. We
are about ready to commit it to the tree (mostly performance tuning, etc.) It
appears to be very stable and really spiffs up big memory machines (>16MB).
The FreeBSD V2.1 scheme does Linux one better (please -- no flames) by
allowing writable mmaps (also fully supporting filling in sparse files.) The
merged VM/Buffer scheme in FreeBSD V2.1 is fully coherent. I have had
previous versions and incarnations of the scheme running since before V1.1.5,
but it is a *major* commitment to get the code, modifications and testing in.
The beauty of the FreeBSD V2.1 scheme is that it does not impact the upper
layers (and most of the lower layers) of the filesystems. The scheme is still
(struct buf *) based.
Advantages of the FreeBSD scheme:
1) Memory starvation problems are very much under control.
2) Huge backlogs of disk output are not possible.
Disadvantages of the FreeBSD scheme:
1) (Currently) Slightly higher overhead --> overall performance
does not suffer though.
2) (Currently) The in-memory data structures (vm_objects, etc)
are slightly too big, but again overall performance is not
bad at all.
Initially, I was going to implement it as a "kernel mmap" scheme. That is
ok, except requires rewriting all of the lower level filesystem code.
Additionally,
it is tricky to implement meta-data caching through the "kernel mmap" scheme.
The scheme that FreeBSD will be using (as I said, should be commited to the
CVS tree in about 1wk or less), also can cache the file meta-data in the merged
cache. Compiles can become deadly silent (no disk chatter) on >16MB machines.
Smaller machines currently show little or no performance degradation. There
were some mess-ups in the pageout daemon in 1.1.5 and 2.0 that did not
manifest themselves significantly until the very dynamic memory requirements
of the merged VM/Buffer cache scheme was implemented. David Greenman
and I are right on the verge of fixing that with a very much simplified
(yet enhanced) pageout daemon. (DG is working from the ground-up and
I am removing garbage from the -current one --> hopefully we'll merge!!!)
>
>* what does act, inact, and wirded memory mean (in top or vmstat) ?
>
WIRED pages (ever watch Dune???) :-), are basically pages that aren't allowed
to move or be paged out. Usually pages are wired when mapped into the
kernel for buffers, kernel malloc areas, etc. Active pages are pages that
have been recently used and are not candidates for being written out to swap
space or being freed. Inactive pages are pages that are candidates for being
written out to swap space or freed. FreeBSD V2.1 will have another category
called "cached" pages --> for the VM/Buffer cache stuff.
dyson@root.com