aboutsummaryrefslogtreecommitdiff
path: root/sys/miscfs/procfs
diff options
context:
space:
mode:
authorJohn Dyson <dyson@FreeBSD.org>1998-01-06 05:26:17 +0000
committerJohn Dyson <dyson@FreeBSD.org>1998-01-06 05:26:17 +0000
commit95e5e988e0185323f57093b8cb1202e130b57314 (patch)
treeca94c084166ef1096c7e4961bb3d03a629ff0c53 /sys/miscfs/procfs
parentdd30ff81d91557627625903be1c94bb47646dce1 (diff)
downloadsrc-95e5e988e0185323f57093b8cb1202e130b57314.tar.gz
src-95e5e988e0185323f57093b8cb1202e130b57314.zip
Make our v_usecount vnode reference count work identically to the
original BSD code. The association between the vnode and the vm_object no longer includes reference counts. The major difference is that vm_object's are no longer freed gratuitiously from the vnode, and so once an object is created for the vnode, it will last as long as the vnode does. When a vnode object reference count is incremented, then the underlying vnode reference count is incremented also. The two "objects" are now more intimately related, and so the interactions are now much less complex. When vnodes are now normally placed onto the free queue with an object still attached. The rundown of the object happens at vnode rundown time, and happens with exactly the same filesystem semantics of the original VFS code. There is absolutely no need for vnode_pager_uncache and other travesties like that anymore. A side-effect of these changes is that SMP locking should be much simpler, the I/O copyin/copyout optimizations work, NFS should be more ponderable, and further work on layered filesystems should be less frustrating, because of the totally coherent management of the vnode objects and vnodes. Please be careful with your system while running this code, but I would greatly appreciate feedback as soon a reasonably possible.
Notes
Notes: svn path=/head/; revision=32286
Diffstat (limited to 'sys/miscfs/procfs')
-rw-r--r--sys/miscfs/procfs/procfs_map.c4
-rw-r--r--sys/miscfs/procfs/procfs_vnops.c9
2 files changed, 5 insertions, 8 deletions
diff --git a/sys/miscfs/procfs/procfs_map.c b/sys/miscfs/procfs/procfs_map.c
index 184cee97a477..7033e1cea7ba 100644
--- a/sys/miscfs/procfs/procfs_map.c
+++ b/sys/miscfs/procfs/procfs_map.c
@@ -36,7 +36,7 @@
*
* @(#)procfs_status.c 8.3 (Berkeley) 2/17/94
*
- * $Id: procfs_map.c,v 1.12 1997/08/02 14:32:12 bde Exp $
+ * $Id: procfs_map.c,v 1.13 1997/11/14 22:57:46 tegge Exp $
*/
#include <sys/param.h>
@@ -101,7 +101,7 @@ procfs_domap(curp, p, pfs, uio)
continue;
obj = entry->object.vm_object;
- if (obj && (obj->ref_count == 1))
+ if (obj && (obj->shadow_count == 1))
privateresident = obj->resident_page_count;
else
privateresident = 0;
diff --git a/sys/miscfs/procfs/procfs_vnops.c b/sys/miscfs/procfs/procfs_vnops.c
index b8bd8e97a228..00cca893ed16 100644
--- a/sys/miscfs/procfs/procfs_vnops.c
+++ b/sys/miscfs/procfs/procfs_vnops.c
@@ -36,7 +36,7 @@
*
* @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95
*
- * $Id: procfs_vnops.c,v 1.50 1997/12/27 02:56:25 bde Exp $
+ * $Id: procfs_vnops.c,v 1.51 1998/01/06 01:37:12 sef Exp $
*/
/*
@@ -186,7 +186,7 @@ procfs_close(ap)
* vnode. While one would expect v_usecount to be 1 at
* that point, it seems that (according to John Dyson)
* the VM system will bump up the usecount. So: if the
- * usecount is 2, and VVMIO is set, then this is really
+ * usecount is 2, and VOBJBUF is set, then this is really
* the last close. Otherwise, if the usecount is < 2
* then it is definitely the last close.
* If this is the last close, then it checks to see if
@@ -197,10 +197,7 @@ procfs_close(ap)
* told to stop on an event, but then the requesting process
* has gone away or forgotten about it.
*/
- if (((ap->a_vp->v_usecount == 2
- && ap->a_vp->v_object
- && (ap->a_vp->v_flag & VVMIO)) ||
- (ap->a_vp->v_usecount < 2))
+ if ((ap->a_vp->v_usecount < 2)
&& (p = pfind(pfs->pfs_pid))
&& !(p->p_pfsflags & PF_LINGER)) {
p->p_stops = 0;