On 01/19/2017 06:52 AM, Hannes Reinecke wrote:
> On 01/19/2017 03:46 PM, Christoph Hellwig wrote:
>> On Thu, Jan 19, 2017 at 03:17:45PM +0100, Hannes Reinecke wrote:
>>> When we're hitting a busy condition in queuecommand() we need to
>>> stop the hardware queue before calling blk_mq_delay_queue(); if
>>> we don't blk_mq_delay_queue() will not do anything and requeue
>>> will never triggered.
>>
>> I suspect the stop needs to move into blk_mq_delay_queue to make
>> it more useful.
>>
> Which is what I've suggested to Jens, too.
> And he even agreed to it :-)
Yeah, I made that patch and grepped the tree. The usage in the fc
code in nvme looks weird. It's stopping all potential hardware queues,
yet only delaying one.
if (op->rq) {
blk_mq_stop_hw_queues(op->rq->q);
blk_mq_delay_queue(queue->hctx, NVMEFC_QUEUE_DELAY);
}
return BLK_MQ_RQ_QUEUE_BUSY;
James/Christoph, what's going on there? I'm going to leave that one
as-is for now, but add the stop to the delay. If the above stop-all is
indeed buggy, then it can later just be removed.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
