From owner-freebsd-hackers Tue Apr 10 18:44: 4 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from netbank.com.br (garrincha.netbank.com.br [200.203.199.88]) by hub.freebsd.org (Postfix) with ESMTP id 0CA5F37B422 for ; Tue, 10 Apr 2001 18:43:57 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from surriel.ddts.net (1-152.cwb-adsl.brasiltelecom.net.br [200.193.160.152]) by netbank.com.br (Postfix) with ESMTP id 2FCB546819; Tue, 10 Apr 2001 22:43:58 -0300 (BRST) Received: from localhost (fauxtc@localhost [127.0.0.1]) by surriel.ddts.net (8.11.2/8.11.2) with ESMTP id f3B1YJf03218; Tue, 10 Apr 2001 22:34:23 -0300 Date: Tue, 10 Apr 2001 22:34:19 -0300 (BRST) From: Rik van Riel X-Sender: riel@imladris.rielhome.conectiva To: Matt Dillon Cc: David Xu , freebsd-hackers@FreeBSD.ORG Subject: Re: vm balance In-Reply-To: <200104102321.f3ANLP994366@earth.backplane.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 10 Apr 2001, Matt Dillon 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). > Well, the approach we take is that of a two-layered cache. > The vnode, dentry (namei for FreeBSD), and inode caches > in FreeBSD are essentially throw-away caches of data > represented in an internal form. The VM PAGE cache 'backs' > these caches loosely by caching the physical on-disk representation > of inodes, and directory entries (see note 1 at bottom). > > This means that even though we limit the number of the namei > and inode structures we keep around in the kernel, the data > required to reconstitute those structures is 'likely' to > still be in the VM PAGE cache, allowing us to pretty much > throw away those structures on a whim. The only cost is that > we have to go through a filesystem op (possibly not requiring I/O) > to reconstitute the internal structure. Which is ok if there isn't too much activity with these data structures, but I'm not sure if it works when you have a lot of metadata activity (though I'm not sure in what kind of workload you'd see this). Also, if you have a lot of metadata activity, you'll essentially double the memory requirements, since you'll have the stuff cached in both the internal structures and in the VM PAGE cache. I'm not sure how much of a hit this would be, though, if the internal structures are limited to a small enough size... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message