From owner-freebsd-hackers Tue Oct 16 19:29:59 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0AEA037B403; Tue, 16 Oct 2001 19:29:54 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9H2Tph84237; Tue, 16 Oct 2001 19:29:51 -0700 (PDT) (envelope-from dillon) Date: Tue, 16 Oct 2001 19:29:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200110170229.f9H2Tph84237@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: John Baldwin , hackers@FreeBSD.ORG Subject: Re: Some questions regarding vfs / ffs References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :John Baldwin writes: :> Not quite. You see, when we set the mount vnode pointer inside the :> vnode, we get the mntvnode mutex while holding the vnode interlock, :> so the order is thus vnode -> mntvnode. So, the ffs_sync() loop :> can't lock the vnode while holding the mntvnode lock. It actually :> used to do that. : :You're basically agreeing with me :) ffs_sync() releases the mntvnode :lock early so it can grab the vnode lock, but if I'm right about it :not needing the vnode lock yet at that point, it can gold the mntvnode :lock longer - until after it's decided whether or not the vnode needs :syncing - which means one less mntnode lock release / acquisition and :one less vnode lock acquisition / release per non-dirty vnode, :reducing the number of lock operations per vnode from four to nearly :zero (as the ratio of dirty vnodes to clean vnodes is usually very :low, the average number of lock operations per vnode examined will :approach zero) : :DES :-- :Dag-Erling Smorgrav - des@ofug.org This would be an improvement, but not enough of an improvement. We need to be able to discard most of the vnodes while simply holding the mntvnode mutex, without even having to get the vnode mutex or release the mntvnode mutex. When we find a vnode that 'might' require some action, that's when we do the heavy-weight mutex junk. At least in the case where it's ok to occassionally not get it right (which is most cases). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message