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: <D1Mz10.2Fo@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> <MICHAELV.94Dec30100718@MindBender.HeadCandy.com> Date: Fri, 30 Dec 1994 18:22:12 GMT Lines: 41 >In article <MICHAELV.94Dec30100718@MindBender.HeadCandy.com> Michael L. VanLoon writes: > >Ugh. How is a unified buffer cache "linux-like"??? That's like >saying using four wheels on a car is "Chevy-like". Linux-mania is >reaching epic proportions. > I agree :-). But you have to admit that Linux is better than CPM or DOS :-). (* The above was meant with good cheer!!! *) > >From what I remember, FreeBSD 2.1 is supposed to have a unified buffer >cache. NetBSD is sticking with the traditional buffer approach for >awhile. The unified buffer cache approach can make some things much >faster, in certain cases, but it can also present some interesting >problems that bring your system to its knees if not tuned right. It's >not a guaranteed win in all circumstances. > You are so right about the problems with merged VM/Buffer schemes causing problems. One very famous UNIX-clone (SVR4) :-) sometimes has some curious problems with starvation and backlogged output. The new FreeBSD scheme is a significant departure from the other schemes that I have seen, and is actually very simple. The serious problems with the dynamic memory needs are real, and we have pretty much eliminated them. In the worst case, the FreeBSD scheme performs about the same, and in the better cases it really performs much better. We made other mods to the vfs layer to support clustering better also. Many, many performance improving cluster opportunities were missed in the original 4.4Lite code... Of course, excess clustering can starve memory if done at the wrong time. dyson@root.com