Date: Mon, 5 Aug 1996 12:08:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: michaelh@cet.co.jp (Michael Hancock) Cc: dfr@render.com, terry@lambert.org, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... Message-ID: <199608051908.MAA11762@phaeton.artisoft.com> In-Reply-To: <Pine.SV4.3.93.960805190943.19666A-100000@parkplace.cet.co.jp> from "Michael Hancock" at Aug 5, 96 07:42:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. It's not the Intel cache being saved, it's the buffer cache in the "valid buffers are in core but not reclaimable without a disk I/O because of the vnode being diassociated from the underlying inode" case. The locality of reference issue is a good point. That is why I was suggesting that a directory name cache entry be treated as a reference instance on the counting semaphore. Since the graphs are complexly connected (sparse linear graph for buffer cache vs. top-fill hierarchical traversal graph for the directory structure), there is need for a second cache; the ihash is bad for this because it is FS specific, and because it is a linear locality model, just like the buffer cache; the only difference is the hash deals with the sparseness. I think this fixes your temporal argument applied to the buffer cache (instead of the processor cache, which I was not considering). You want to avoid the reassociation penalty. Since the buffers are hung off the vnode, the ihash savings are minimal following a hit (which will only occur after a dissociation. In both cases, the good data in core has had its references invalidated, and can't be recovered without a disk I/O (hence my remarks about the ihash about four weeks ago). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608051908.MAA11762>