Date: Mon, 5 Aug 1996 10:33:45 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Doug Rabson <dfr@render.com> 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.SV4.3.93.960805102421.16654A-100000@parkplace.cet.co.jp> In-Reply-To: <Pine.BSI.3.95.960803163842.1451A-100000@nlsys.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960805102421.16654A-100000>