[PATCH] nvme: add a module parameter to change queue depth
Masayoshi Mizuma
m.mizuma at jp.fujitsu.com
Tue Jul 5 01:09:36 PDT 2016
On Mon, 4 Jul 2016 01:49:40 -0700 Christoph Hellwig wrote:
> On Mon, Jul 04, 2016 at 05:33:20PM +0900, Masayoshi Mizuma wrote:
>> This patch adds "q_depth_limit" as a module parameter. nvme_queue->q_depth
>> is set below q_depth_limit.
>>
>> while loop at __nvme_process_cq() sometimes takes long time and
>> the loop is under IRQ context, so system slow down and hardlockup
>> may occur because of the loop.
>>
>> The while loop runs nvme_queue->q_depth times and the q_depth is set
>> by the following (NVME_Q_DEPTH is 1024).
>>
>> dev->q_depth = min_t(int, NVME_CAP_MQES(cap) + 1, NVME_Q_DEPTH);
>>
>> To reduce the times of the loop, the q_depth_limit is useful.
>>
>> In addition, this patch moves the temporary fix for the Apple controller
>> into the new function, get_q_depth().
>
> While limiting the queue depth might still be useful I think we need
> to look into a potential lock break in __nvme_process_cq so that it
> doesn't cause hard lockups even with large queue depth first.
Yes, the module parameter is useful as a workaround to avoid hard lockup.
I agree that we should look into nvme_queue->q_lock lock break
in __nvme_process_cq().
However, if __nvme_process_cq() is called by nvme_irq() in IRQ context,
the hard lockup may happen even if nvme_queue->q_lock is unlocked.
This is because timer interrupt is disabled while the IRQ context.
- Masayoshi Mizuma
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
More information about the Linux-nvme
mailing list