From owner-freebsd-hackers Sat Mar 18 00:56:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA24530 for hackers-outgoing; Sat, 18 Mar 1995 00:56:25 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA24524 for ; Sat, 18 Mar 1995 00:56:22 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id AAA19109; Sat, 18 Mar 1995 00:56:18 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id AAA00132; Sat, 18 Mar 1995 00:56:18 -0800 Message-Id: <199503180856.AAA00132@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: "Justin T. Gibbs" cc: hackers@freefall.cdrom.com Subject: Re: SVNET Meeting? In-reply-to: Your message of "Sat, 18 Mar 95 00:22:45 PST." <199503180822.AAA18883@estienne.cs.berkeley.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Sat, 18 Mar 1995 00:56:17 -0800 Sender: hackers-owner@FreeBSD.org Precedence: bulk >3) There has been some discussion in the NetBSD mailing lists about >NetBSD's VM system, the fixed size buffer cache, and whether we're >best utilizing availible memory. Is there any research being done >in this area? > > J.T. was very honest in pointing to FreeBSDs totally revamped VM > system as a new aproach to these problems. He said that NetBSD > currently lacks the resources to address this problem, but also > stated that not everyone agreed that the FreeBSD aproach was the > the best one to take. John and I will be the first to admit that, in a perfect world, the merged cache scheme that has been implemented in FreeBSD is not the best that can be done. Unfortunately, doing it the "right way" requires gutting large sections of the filesystem code and making large complex changes to the fundamental structure of the system. When faced with this and the alternative (which was to change/extend the way that buffers worked), the latter was the clear choice given our current resources. As a bonus, it actually ended up working better than we originally thought it would, and sides step many of the problems that plague the "best" approach. >to other operating systems. I assured them, and I hope that the rest >of core agrees, that stability, even if it means postponing the release, >will be our primary goal. Cetainly...Jordan, Poul, John, and myself have all expressed our violent agreement on this; 2.1R won't be released until it is more stable than 1.1.5. -DG