Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 May 2005 12:14:48 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Scott Long <scottl@samsco.org>
Cc:        Daniel Eriksson <daniel_k_eriksson@telia.com>, freebsd-arch@freebsd.org
Subject:   Re: MPSAFE CAM?
Message-ID:  <20050529121224.L52379@fledge.watson.org>
In-Reply-To: <4298E316.9020303@samsco.org>
References:  <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAvHxW/c0DGk+3ez1DZggmFgEAAAAA@telia.com> <4298E316.9020303@samsco.org>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On Sat, 28 May 2005, Scott Long wrote:

> If anyone wants to help tackle this, I'd be glad to help them get 
> started.  BSD/OS 5.(mumble) did a minimal locking job on CAM that 
> probably works OK for systems with a single SCSI port, but likely gets 
> very inefficient once you go beyond that.  They also rewrote the SCSI 
> probe state machine, which in our CAM is a source for quite a bit of 
> lock recursion.  The work I did last year focused on addressing this.

The good news is that with VFS and UFS out from under Giant, code left 
running under Giant experiences a lot less contention than it used to. 
So once the interrupt handler can run to completion without Giant in a CAM 
driver, we've gained many of the benefits of making MPSAFE.  Especially if 
we can knock Giant off a lot of the remaining non-CAM device drivers that 
it's still stuck over.

Another area that requires further attention is the tty code and tty 
drivers.  It sounds like phk has some plans in this space, and as I told 
him at BSDCan, I'm happy to do the network side of tty-connected network 
code, if he takes care of the tty side.  Once this is done, maybe someone 
can give another try at syscons...

Robert N M Watson



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20050529121224.L52379>