From owner-freebsd-hackers Wed Jan 21 15:30:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10155 for hackers-outgoing; Wed, 21 Jan 1998 15:30:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09996 for ; Wed, 21 Jan 1998 15:29:44 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA00838; Wed, 21 Jan 1998 16:29:35 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd000821; Wed Jan 21 16:29:33 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA12160; Wed, 21 Jan 1998 16:29:30 -0700 (MST) From: Terry Lambert Message-Id: <199801212329.QAA12160@usr09.primenet.com> Subject: Re: Locking on disk slice I/O--yes, no or how? To: toor@dyson.iquest.net (John S. Dyson) Date: Wed, 21 Jan 1998 23:29:29 +0000 (GMT) Cc: tlambert@primenet.com, grog@lemis.com, hackers@FreeBSD.ORG In-Reply-To: <199801212304.SAA29056@dyson.iquest.net> from "John S. Dyson" at Jan 21, 98 06:04:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > > I'm currently trying to perform low-level I/O to disk slices in a > > > driver. I've read section 9 of the manual, which tells me that all > > > reads and writes should be protected with a VOP_LOCK/VOP_UNLOCK pair. > > > I've tried this, and get a panic: "lockmgr: locking against myself" > > > > Yick. Someone's trying to use the lockmgr for finer grained SMP > > locking. That'll never work... it must have snuck in when I wasn't > > looking. > > Terry, > I think that your answer is orthogonal to the question asked. Also, > lockmgr is perfect (except for being slightly high overhead) for the purpose > that it is being used. I am moving towards a TSM scheme for both better > UP and SMP performance. > > When my work settles down, I will try to help with some of the questions that > have come across my mailbox in the last week or so. He can't call VOP_LOCK because he's in the kernel, and there's a different lock asserted because of the way he got there. Either you're supposed to call VOP_LOCK to protect the vnode from being reentered, or you're not, right? IMO, he shouldn't be getting the panic, and it should work, unless he's trying to call the thing at interrupt time from the driver for the device he's attempting to write to. The panic occurs because, in an attempt to get finer grained locking, the lock space was normalized against deadlocks by unifying it instead of adding hierarchy. Actually, I'd be interested in using opportunity locking with an intention mode hierarchical lock manager. We were able to do ~20,000 transactions a second using this as the lock manager in the NetWare for UNIX product, technically a hosted OS. Only if you have an intention collision would you resort to a TSM call to resolve the collision. For the most part, it's non-blocking. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.