From owner-freebsd-arch@FreeBSD.ORG Tue Jan 11 22:54:46 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 5FC1016A4CE for ; Tue, 11 Jan 2005 22:54:46 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D68A943D46 for ; Tue, 11 Jan 2005 22:54:45 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so397229wri for ; Tue, 11 Jan 2005 14:54:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=j7j6j7fmrMjDWHR0+3vjJ1SmvGRrqQAixWBEHBGeSssMoaaMBeinj8TP2IY24lkW7ixlB0lNaPi5XiVwSPAnMWa7uknNBBT5JUufM2wRqRK3OgPdniIIN1MtvCj2FLzfFGfldtZvgBu2evvk02mIJvyOqHs5WEL277i8QfZnCAk= Received: by 10.54.27.60 with SMTP id a60mr302695wra; Tue, 11 Jan 2005 14:54:45 -0800 (PST) Received: by 10.54.57.76 with HTTP; Tue, 11 Jan 2005 14:54:45 -0800 (PST) Message-ID: <34cb7c84050111145415980aa2@mail.gmail.com> Date: Tue, 11 Jan 2005 22:54:45 +0000 From: Peter Edwards To: Poul-Henning Kamp In-Reply-To: <23763.1105479646@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <23763.1105479646@critter.freebsd.dk> 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 Reply-To: Peter Edwards 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 22:54:46 -0000 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 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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >