> -----Original Message----- > From: Jens Axboe [mailto:axboe@xxxxxxxxx] > Sent: Monday, January 30, 2017 10:03 PM > To: Bart Van Assche; osandov@xxxxxxxxxxx; kashyap.desai@xxxxxxxxxxxx > Cc: linux-scsi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > hch@xxxxxxxxxxxxx; linux-block@xxxxxxxxxxxxxxx; paolo.valente@xxxxxxxxxx > Subject: Re: Device or HBA level QD throttling creates randomness in > sequetial workload > > On 01/30/2017 09:30 AM, Bart Van Assche wrote: > > On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: > >> - if (atomic_inc_return(&instance->fw_outstanding) > > >> - instance->host->can_queue) { > >> - atomic_dec(&instance->fw_outstanding); > >> - return SCSI_MLQUEUE_HOST_BUSY; > >> - } > >> + if (atomic_inc_return(&instance->fw_outstanding) > safe_can_queue) { > >> + is_nonrot = blk_queue_nonrot(scmd->device->request_queue); > >> + /* For rotational device wait for sometime to get fusion > >> + command > >> from pool. > >> + * This is just to reduce proactive re-queue at mid layer > >> + which is > >> not > >> + * sending sorted IO in SCSI.MQ mode. > >> + */ > >> + if (!is_nonrot) > >> + udelay(100); > >> + } > > > > The SCSI core does not allow to sleep inside the queuecommand() > > callback function. > > udelay() is a busy loop, so it's not sleeping. That said, it's obviously NOT a > great idea. We want to fix the reordering due to requeues, not introduce > random busy delays to work around it. Thanks for feedback. I do realize that udelay() is going to be very odd in queue_command call back. I will keep this note. Preferred solution is blk mq scheduler patches. > > -- > Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
