From owner-freebsd-hackers Tue Oct 16 18:12: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 0251637B409; Tue, 16 Oct 2001 18:12:00 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4160B14C2E; Wed, 17 Oct 2001 03:11:58 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: hackers@freebsd.org Cc: dillon@freebsd.org Subject: Some questions regarding vfs / ffs From: Dag-Erling Smorgrav Date: 17 Oct 2001 03:11:57 +0200 Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Why do we have a single mntvnode_mtx instead of one per struct mount? It's supposed to protect the (per-mount) vnode list, so logically it should be a per-mount mutex. The only reason I can find for it being global is that it saves a few keystrokes in insmntque(). This is the only place I've found where mntvnode_mtx is held and more than one mount is invloved. Why does ffs_sync() grab the vnode interlock before checking if the vnode is dirty? As far as I can determine (from comments in the headers), none of the information it examines is protected by the interlock. Are the comments wrong, or is the code wrong? If the code is wrong, then this is what is killing interrupt latency on my box: needlessly acquiring and releasing 40,000 or 60,000 vnode interlocks twice per minute. Also, ffs_sync() does a lot of locking and unlocking of mntvnode_mtx, when actually (I think) it could get away with just unlocking it briefly while actually syncing a vnode, and holding it the rest of the time. I believe the reason why it currently does what it does is to avoid a lock reversal between mntvnode_mtx and the vnode locks. This won't be a problem if I'm right about the vnode lock being held unnecessarily. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message