On 4/23/26 2:45 AM, Hannes Reinecke wrote:
Ideally I would kill cmd_per_lun. This really is a poor man's fairness algorithm (sole purpose is to avoid starvation with many luns), and we really should look at if we cannot replace it with tagsets.
Hmm ... isn't cmd_per_lun essential since the introduction of scsi-mq? Without a host-wide tagset, and with n hardware queues, blk_mq_alloc_tag_set() allocates (number of hardware queues) * (shost->can_queue + shost->nr_reserved_cmds) requests. Each request maps to one SCSI command. Setting cmd_per_lun to shost->can_queue may be essential to avoid BUSY responses from a SCSI device. Here is an example from the ib_srp driver (there are many more SCSI LLDs that follow this pattern): * During connection establishment, the SCSI target reports the maximum queue depth it supports. This response is used to initialize can_queue and cmd_per_lun. * Multiple hardware queues are allocated, all supporting can_queue commands. * cmd_per_lun is set to can_queue to avoid BUSY responses from the SCSI target. My experience is that for high performance SCSI targets even 1% BUSY responses cause a significant performance drop. Thanks, Bart.
