Date: Tue, 11 Jan 2005 22:40:46 +0100 From: Poul-Henning Kamp <phk@phk.freebsd.dk> To: arch@freebsd.org Subject: Slight change of vnode<-->vm object relationship. Message-ID: <23763.1105479646@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23763.1105479646>