From owner-freebsd-current Mon Aug 5 03:09:43 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA06278 for current-outgoing; Mon, 5 Aug 1996 03:09:43 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA06269 for ; Mon, 5 Aug 1996 03:09:40 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id LAA10099; Mon, 5 Aug 1996 11:10:02 +0100 Date: Mon, 5 Aug 1996 11:10:00 +0100 (BST) From: Doug Rabson To: Michael Hancock cc: Terry Lambert , jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 5 Aug 1996, Michael Hancock wrote: > On Sat, 3 Aug 1996, Doug Rabson wrote: > > > > The vclean code is evil and redundant and redundant, but without moving > > > the vnode allocation to per FS vnodes (I've mentioned this before), there > > > is very little you can do. It's a buffer cache lose to say "no" to a > > > page that's in core, but which does not have a vnode referencing it, > > > so you have to reload it from disk even though a perectly good copy > > > is already in memory. 8-(. > > > > You have to start reusing vnodes sometime. Whether it means reusing them > > within a filesystem or across a global pool, it has to happen. Even > > reusing a vnode within a filesystem would involve something similar to > > vclean() surely. I don't understand the VM system well enough to judge > > whether dropping a few valid pages from old vnodes is a real problem in > > performance terms. > > I think what he's is saying is that when the vnodes are in the global pool > the chances of reusing a vnode that was used previously by a particular fs > is less than having a per fs vnode pool. > > The problem with the per fs vnode pool is the management overhead. When > you need to start reusing vnodes you need to search through all the > different fs pools to find a vnode. > > I don't know which is a better trade-off. But surely, even if you find a vnode from the same filesystem, you still need to 'clean' it, i.e. invalidate buffers and re-associate with a different inode+dev/filehandle/whatever. I don't see what the gain for per-fs vnode pools is. I expect Terry will explain it to me now :-) -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939