From owner-freebsd-arch@FreeBSD.ORG Tue Jan 11 23:51:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84EFB16A4CF for ; Tue, 11 Jan 2005 23:51:34 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 98E8743D3F for ; Tue, 11 Jan 2005 23:51:33 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 32193 invoked by uid 89); 11 Jan 2005 23:51:17 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 11 Jan 2005 23:51:17 -0000 Received: (qmail 30822 invoked by uid 89); 11 Jan 2005 23:50:29 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 11 Jan 2005 23:50:29 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j0BNnuNg057720; Tue, 11 Jan 2005 18:50:06 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: Poul-Henning Kamp In-Reply-To: <23763.1105479646@critter.freebsd.dk> References: <23763.1105479646@critter.freebsd.dk> Content-Type: text/plain Message-Id: <1105487395.57137.26.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 11 Jan 2005 18:49:56 -0500 Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Slight change of vnode<-->vm object relationship. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 23:51:34 -0000 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