Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Jan 1998 23:29:29 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        toor@dyson.iquest.net (John S. Dyson)
Cc:        tlambert@primenet.com, grog@lemis.com, hackers@FreeBSD.ORG
Subject:   Re: Locking on disk slice I/O--yes, no or how?
Message-ID:  <199801212329.QAA12160@usr09.primenet.com>
In-Reply-To: <199801212304.SAA29056@dyson.iquest.net> from "John S. Dyson" at Jan 21, 98 06:04:58 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801212329.QAA12160>