On 01/30/2017 11:28 AM, Kashyap Desai wrote: >> -----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. It's coming in 4.11, so you don't have to wait long. -- 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
