Nate Lawson wrote:
> Sean Bruno wrote:
>> Alrighty, a little cleaner patch to allow
sbp_targ.c to acutally work
>> under RELENG_6. http://www.co
nsultcsg.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.con
sultcsg.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
_______________________________________________
freebsd-firewire freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fire
wire
To unsubscribe, send any mail to
"freebsd-firewire-unsubscribefreebsd.org"
|
