Re: [PATCH RFC v7 10/12] megaraid_sas: switch fusion adapters to MQ

[John Garry <john.garry@huawei.com>]

>>>>>>
>>>>>> diff --git a/block/blk-mq.c b/block/blk-mq.c index
>>>>>> 1be7ac5a4040..b6a5b41b7fc2 100644
>>>>>> --- a/block/blk-mq.c
>>>>>> +++ b/block/blk-mq.c
>>>>>> @@ -1559,6 +1559,9 @@ void blk_mq_run_hw_queues(struct
>>>>> request_queue
>>>>>> *q, bool async)
>>>>>>          struct blk_mq_hw_ctx *hctx;
>>>>>>          int i;
>>>>>>
>>>>>> +       if (!q->elevator)
>>>>>> +               return;
>>>>>> +
>>>>> This way shouldn't be correct, blk_mq_run_hw_queues() is still
>>>>> needed

Could the logic of blk_mq_run_hw_queue() -> blk_mq_hctx_has_pending() -> 
sbitmap_any_bit_set(&hctx->ctx_map) be optimised for megaraid scenario?

As I see, since megaraid will have 1:1 mapping of CPU to hw queue, will 
there only ever possibly a single bit set in ctx_map? If so, it seems a 
waste to always check every sbitmap map. But adding logic for this may 
negate any possible gains.

>>>> for
>>>>> none because request may not be dispatched successfully by direct
>> issue.
>>>> When block layer attempt posting request to h/w queue directly (for
>>>> ioscheduler=none) and if it fails, it is calling
>>>> blk_mq_request_bypass_insert().
>>>> blk_mq_request_bypass_insert function will start the h/w queue from
>>>> submission context. Do we still have an issue if we skip running hw
>>>> queue from completion ?
>>> The thing is that we can't guarantee that direct issue or adding request
>> into
>>> hctx->dispatch is always done for MQ/none, for example, request still
>>> can be added to sw queue from blk_mq_flush_plug_list() when mq plug is
>>> applied.
>> I see even blk_mq_sched_insert_requests() from blk_mq_flush_plug_list make
>> sure it run the h/w queue. If all the submission path which deals with s/w
>> queue make sure they run h/w queue, can't we remove blk_mq_run_hw_queues()
>> from scsi_end_request ?
> No, one purpose of blk_mq_run_hw_queues() is for rerun queue in case that
> dispatch budget is running out of in submission path, and sdev->device_busy is
> shared by all hw queues on this scsi device.
> 
> I posted one patch for avoiding it in scsi_end_request() before, looks it
> never lands upstream:
> 

I saw that you actually posted the v3:
https://lore.kernel.org/linux-scsi/BL0PR2101MB11230C5F70151037B23C0C35CE2D0@BL0PR2101MB1123.namprd21.prod.outlook.com/
And it no longer applies, due to the changes in scsi_mq_get_budget(), I 
think, which look non-trivial. Any chance to repost?

Thanks,
John