Date: Wed, 12 Dec 2007 14:42:23 -0700 From: Scott Long <scottl@samsco.org> To: Nate Lawson <nate@root.org> Cc: freebsd-firewire@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: scsi_target witness lock error Message-ID: <476055BF.90808@samsco.org> In-Reply-To: <4760446D.2060102@root.org> References: <1197420795.2738.6.camel@iago.office.miralink.com> <86sl28snpe.wl%simokawa@FreeBSD.ORG> <1197425759.14437.0.camel@home-desk> <626eb4530712111837y4608e919w845461d36a18118f@mail.gmail.com> <475F5669.1010800@miralink.com> <476034FE.7080003@miralink.com> <4760446D.2060102@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote: > Sean Bruno wrote: >> Alrighty, a little cleaner patch to allow sbp_targ.c to acutally work >> under RELENG_6. http://www.consultcsg.com/RELENG_6.diff >> >> Also and update with the witness error. And the kernel config I am using: >> http://www.consultcsg.com/scsitarget_witness.txt >> http://www.consultcsg.com/FIREWIRE_TGT >> >> Is scsi_target the only application that is making this kern env witness >> error appear? I find it hard to believe that nothing else in the code >> base hits this type of problem? > > Apparently scsi_target wasn't fully tested when the CAM locking went in. Yep, hate to say it, it dropped off my radar. Sorry. > It was written before there was a design for CAM locking so it may need > some reworking. For example, it assumes that it should acquire/drop > locks multiple times in its start method if there are multiple CCBs > queued. That may not be the fastest way, depending on contention for > the SIM lock. > I've found that grabbing+dropping a lock in a loop is really, really bad for performance critical paths. The cost of the atomic ops is trivial, but the cost of contention is huge. The same is true of grabbing and dropping locks in a long linear path. Imagine driving down a street with a lot of stoplights, and each stoplight is sensor-triggered by cross traffic. Even if cross-traffic is light and you only have to stop for one light, and that one light is really short, you still loose a lot of time from slowing down and then speeding back up. You could imagine that it would be a lot faster to have all lights stay green for you. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476055BF.90808>