Re: [PATCH v2 12/12] IB/srp: Add multichannel support

[Sagi Grimberg <sagig@dev.mellanox.co.il>]

On 10/29/2014 2:36 PM, Bart Van Assche wrote:
> On 10/21/14 11:14, Sagi Grimberg wrote:
>> On 10/7/2014 4:07 PM, Bart Van Assche wrote:
>>>               spin_lock_irqsave(&ch->lock, flags);
>>>               ch->req_lim += be32_to_cpu(rsp->req_lim_delta);
>>> @@ -1906,7 +1970,7 @@ static int srp_queuecommand(struct Scsi_Host
>>> *shost, struct scsi_cmnd *scmnd)
>>>           goto err;
>>
>> Bart,
>>
>> Any chance you can share some perf output on this code?
>> I'm interested of knowing the contention on target->lock that is
>> still taken on the IO path across channels.
>>
>> Can we think on how to avoid it?
>>
>> Also would like to understand the where did the bottleneck transition.
>
> Hello Sagi,
>
> Are you referring to target->lock ? That lock isn't taken anywhere in
> the hot path.

Right, my recollection was that we used to acquire the target-lock in
srp_chkready(). I see that's not the case anymore.

> More in general, I haven't seen any lock contention in the
> perf output that was caused by the block layer, SCSI core, SRP initiator
> or HCA (mlx4) drivers. The code that showed up highest in the perf
> output was the direct I/O code, the code that is triggered by fio to
> submit I/O requests.

Interesting, you don't see more contention on SQ/RQ/CQ locks? I find
that surprising.

Sagi.