Slight change of vnode<-->vm object relationship.

[Peter Edwards]

How about mmap() mappings after the close()? These can persist post
VOP_CLOSE, can't they?


On Tue, 11 Jan 2005 22:40:46 +0100, Poul-Henning Kamp
<phk at phk.freebsd.dk> 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 ?
> 
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>