Date: Tue, 11 Jan 2005 18:49:56 -0500 From: Stephan Uphoff <ups@tree.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: Slight change of vnode<-->vm object relationship. Message-ID: <1105487395.57137.26.camel@palm.tree.com> In-Reply-To: <23763.1105479646@critter.freebsd.dk> References: <23763.1105479646@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2005-01-11 at 16:40, Poul-Henning Kamp wrote: > Today a vnode gets its vm object through an explicit call to > VOP_CREATEVOBJECT() and these calls are scattered all over the place > in code which shouldn't really have to know about this detail. > > It seems to me that it would make much more sense to make it became > the responsibility of VOP_OPEN() and VOP_CLOSE() to manage the vnodes > vm_object. > > First of all, it gets put into the filesystem which implements the > vnode, that's always cleaner, even if it just ends up calling a generic > function to do all the work. > > But second, and from a buffer cache perspective far more important > reason: it makes the VOP_GETVOBJECT() call go away because the > vp->v_object pointer will be stable as long as the vnode is open. > > The vp->v_object pointer is likely to be valid also after the vnode > has been closed, at least as long as there are cached pages in > RAM for the vnode, but again the vp->v_object pointer will tell > us that without a need to call down the stack of vnodes to find out. > > For NULLFS/UNIONFS this works particular elegant: on VOP_OPEN, > the lower vnods v_object is copied to the upper vnode (I don't even > think we need to grab a reference because we already have a reference > on the lower vnode anyway). On VOP_CLOSE we simply zero the v_object > pointer on the upper vnode. The lower vnode will still cache the > object and pages, and if we open again, all we have to do is copy > the pointer. > > Anyone spot what I didn't ? Do you mean VOP_INACTIVE instead of VOP_CLOSE ? VOP_CLOSE is called for every close() call to the file - not just the last close. The NFS server also does not call VOP_OPEN - so this may be another problem. Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1105487395.57137.26.camel>