Date: Mon, 5 Aug 1996 11:10:00 +0100 (BST) From: Doug Rabson <dfr@render.com> To: Michael Hancock <michaelh@cet.co.jp> Cc: Terry Lambert <terry@lambert.org>, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... Message-ID: <Pine.BSI.3.95.960805110745.10082A-100000@minnow.render.com> In-Reply-To: <Pine.SV4.3.93.960805102421.16654A-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960805110745.10082A-100000>