From owner-freebsd-hackers Mon Aug 3 07:14:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29558 for freebsd-hackers-outgoing; Mon, 3 Aug 1998 07:14:31 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29535 for ; Mon, 3 Aug 1998 07:14:26 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id QAA08273; Mon, 3 Aug 1998 16:08:20 +0200 (MET DST) Received: from semyam.dinoco.de (semyam.dinoco.de [127.0.0.1]) by semyam.dinoco.de (8.8.8/8.8.8) with ESMTP id MAA09805; Mon, 3 Aug 1998 12:25:49 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199808031025.MAA09805@semyam.dinoco.de> To: zhihuizhang Cc: freebsd-hackers@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: Relationship between buf/page/vnode/object? In-reply-to: Your message of "Sun, 02 Aug 1998 14:36:28 EDT." Date: Mon, 03 Aug 1998 12:25:48 +0200 From: Stefan Eggers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What confuses me now is that vnode and buf structures can also have pages > (vm_page structures) associated with them. But file system cache and VM > cache are unified and should have a consistent interface. I mean all pages > should only hang off the vm_object structures. Right. I didn't look at this code till yesterday. Taking a deep look at vnode_pager.c and today a bit more on vfs_subr.c and vfs_vnops.c I think I have an idea how this all works. > I hope that someone can describe the relationship of these important > structures (vm_object, vm_page, vnode, buf) briefly for me. I have If someone is seeing an error here please correct me: As I understand it the vnode of a regular file gets a pointer to an associated vm_object on open (in vfs_vnops.c in kern the actual open happens) and this is the same vm_object for the same file opened several times at the same time. With this vm_object the pages for the buffers of this vnode get managed. This vm_object is of type OBJT_VNODE and thus uses the functions in vnode_pager.c for page manipulation. A buf has pointers to vm_page structures which have the memory pages associated with the buffer and a pointer to its vnode. Manipulating them means using the operations in vm_pager.c (which for OBJT_VNODE call the functions in vnode_pager.c) with the vm_object in the vnode. If you mmap a file vm_mmap.c contains the code used. It looks as if it were allocating a new object every time you map a file but this is not what actually happens. The object allocating that finally gets called is the one in vnode_pager.c and is named vnode_pager_alloc. If the vnode it gets already has an object it just increments the use count for the object. Thus the vnode of a regular file has an associated vm_object (which is the same as long as at least one reference to this vnode exists) and every time you reference the file you do it with its vnode. It doesn't matter if it is a read() or a mmap(), all references to it go through the vnode's vm_object and use the functions in vnode_pager.c. I hope it got a bit clearer by this how the whole thing works. And I also hope that I don't wrote too much nonsense - I just started reading about this in the code yesterday night. ;-) Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message