From owner-freebsd-current Mon Aug 5 03:43:31 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA08044 for current-outgoing; Mon, 5 Aug 1996 03:43:31 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA08035 for ; Mon, 5 Aug 1996 03:43:26 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id KAA19813; Mon, 5 Aug 1996 10:42:20 GMT Date: Mon, 5 Aug 1996 19:42:19 +0900 (JST) From: Michael Hancock To: Doug Rabson 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, 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