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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
