From owner-freebsd-current Sun Aug 4 04:13:41 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA29755 for current-outgoing; Sun, 4 Aug 1996 04:13:41 -0700 (PDT) Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA29748 for ; Sun, 4 Aug 1996 04:13:37 -0700 (PDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id ac12344; 4 Aug 96 11:12 GMT Received: from nlsys.demon.co.uk ([158.152.125.33]) by relay-3.mail.demon.net id aa10311; 4 Aug 96 12:09 +0100 Received: from localhost (dfr@localhost) by nlsys.demon.co.uk (8.7.5/8.6.9) with SMTP id MAA01315; Sun, 4 Aug 1996 12:08:03 +0100 (BST) Date: Sun, 4 Aug 1996 12:08:02 +0100 (BST) From: Doug Rabson Reply-To: Doug Rabson To: John Dyson cc: dfr@render.com, terry@lambert.org, jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... In-Reply-To: <199608031914.MAA01882@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 3 Aug 1996, John Dyson wrote: > > > > I just grepped for uses of VOP_LOCK in the kernel and there seem to be a > > few places in the vm system which appear to be using the vnode lock to > > protect critical sections of code. Have a look at vm_object_terminate() > > and vm_object_page_clean() and tell me what would happen if the VOP_LOCK > > is not exclusive. > > > Don't do a vm_object_page_clean if VOP_LOCK is not exclusive :-). Don't > even think about it... I sure don't want to :-). Well NFS' VOP_LOCK is certainly not exclusive, so is that going to be a possible cause of nfs's instability? > > > > > You have to start reusing vnodes sometime. Whether it means reusing them > > within a filesystem or across a global pool, it has to happen. Even > > reusing a vnode within a filesystem would involve something similar to > > vclean() surely. I don't understand the VM system well enough to judge > > whether dropping a few valid pages from old vnodes is a real problem in > > performance terms. > > > If the vnode is on the free queue, there had better not be any processes > using it at the time (the vm_object holds a reference.) If you need to > get a free vnode, you should probably first check the vnode free list > and then perhaps try to check the cached VM objects. Vnode backed > cached VM objects should be able to be terminated at any time (in > process context.) A side-effect of the object termination is that the > vnode will be pretty much available for re-use. I think everything in the system is pretty clean in that respect. Everyone calls vget() to reactivate cached vnodes and checks the return value to make sure it is still ok. I am pretty sure nothing tries to use a vnode with a zero v_usecount. -- Doug Rabson Mail: dfr@nlsys.demon.co.uk Phone: +44 181 951 1891