Date: Mon, 5 Aug 1996 19:42:19 +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.960805190943.19666A-100000@parkplace.cet.co.jp> In-Reply-To: <Pine.BSI.3.95.960805110745.10082A-100000@minnow.render.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Aug 1996, Doug Rabson wrote: > On Mon, 5 Aug 1996, Michael Hancock wrote: > > > 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 :-) I think the gain is the potential processor data caching of the vnode object itself. Having a global vnode pool breaks this locality of reference. But then again since the caching effects are very temporal and the Intel cache is small it's hard to say how much of an effect the per fs pools would have. Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960805190943.19666A-100000>