Re: scsi_target witness lock error

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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "[email protected]"