diff options
author | John Dyson <dyson@FreeBSD.org> | 1998-01-06 05:26:17 +0000 |
---|---|---|
committer | John Dyson <dyson@FreeBSD.org> | 1998-01-06 05:26:17 +0000 |
commit | 95e5e988e0185323f57093b8cb1202e130b57314 (patch) | |
tree | ca94c084166ef1096c7e4961bb3d03a629ff0c53 /sys/miscfs/procfs | |
parent | dd30ff81d91557627625903be1c94bb47646dce1 (diff) | |
download | src-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.c | 4 | ||||
-rw-r--r-- | sys/miscfs/procfs/procfs_vnops.c | 9 |
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; |