From owner-freebsd-hackers Mon Apr 16 23: 2:44 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 7D9B637B424 for ; Mon, 16 Apr 2001 23:02:41 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id XAA55944; Mon, 16 Apr 2001 23:02:19 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200104170602.XAA55944@beastie.mckusick.com> To: Julian Elischer Subject: Re: vm balance Cc: Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu In-Reply-To: Your message of "Tue, 10 Apr 2001 22:14:28 PDT." <3AD3E834.AFB6C5BA@elischer.org> Date: Mon, 16 Apr 2001 23:02:19 -0700 From: Kirk McKusick Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 10 Apr 2001 22:14:28 -0700 From: Julian Elischer To: Rik van Riel CC: Matt Dillon , David Xu , freebsd-hackers@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: vm balance Rik van Riel wrote: > > I'm curious about the other things though ... FreeBSD still seems > to have the early 90's abstraction layer from Mach and the vnode > cache doesn't seem to grow and shrink dynamically (which can be a > big win for systems with lots of metadata activity). > > So while it's true that FreeBSD's VM balancing seems to be the > best one out there, I'm not quite sure about the rest of the VM... > Many years ago Kirk was talking about merging the vm objects and the vnodes.. (they tend to come in pairs anyhow) I still think it might be an idea worth investigating further. kirk? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v I am still of the opinion that merging VM objects and vnodes would be a good idea. Although it would touch a huge number of lines of code, when the dust settled, it would simplify some nasty bits of the system. This merger is really independent of making the number of vnodes dynamic. Under the old name cache implementation, decreasing the number of vnodes was slow and hard. With the current name cache implementation, decreasing the number of vnodes would be easy. I concur that adding a dynamically sized vnode cache would help performance on some workloads. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message