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%2B3ez1DZggmFgEAAAAA@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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050529121224.L52379>