lkml.org 
[lkml]   [2018]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle
    Date
    On Fri, 2018-01-19 at 15:34 +0800, Ming Lei wrote:
    > Could you explain a bit when SCSI target replies with BUSY very often?
    >
    > Inside initiator, we have limited the max per-LUN requests and per-host
    > requests already before calling .queue_rq().

    That's correct. However, when a SCSI initiator and target system are
    communicating with each other there is no guarantee that initiator and target
    queue depth have been tuned properly. If the initiator queue depth and the
    number of requests that can be in flight according to the network protocol
    are both larger than the target queue depth and if the target system uses
    relatively slow storage (e.g. harddisks) then it can happen that the target
    replies with BUSY often.

    The Linux iSCSI initiator limits MaxOutstandingR2T (the number of requests
    an initiator may sent without having received an answer from the target) to
    one so I don't think this can happen when using iSCSI/TCP.

    With the SRP initiator however the maximum requests that can be in flight
    between initiator and target depends on the number of credits that were
    negotiated during login between initiator and target. Some time ago I modified
    the SRP initiator such that it limits the initiator queue depth to the number
    of SRP credits minus one (for task management). That resulted in a performance
    improvement due to fewer BUSY conditions at the initiator side (see also commit
    7ade400aba9a ("IB/srp: Reduce number of BUSY conditions")). Another patch for
    the SCST SRP target driver limited the number of SRP credits to the queue depth
    of the block device at the target side. I'm referring to the following code:
    ch->rq_size = min(MAX_SRPT_RQ_SIZE, scst_get_max_lun_commands(NULL, 0)) (I have
    not yet had the time to port this change to LIO).

    Without such tuning across initiator and target it can happen often that the
    target system sends the reply "BUSY" back to the initiator. I think that's why
    there is code in the SCSI core to automatically adjust the initiator queue
    depth if the "BUSY" condition is encountered frequently. See also
    scsi_track_queue_full().

    Bart.
    \
     
     \ /
      Last update: 2018-01-19 20:48    [W:4.109 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site