On 2020-05-08 19:09, Ming Lei wrote:
> On Fri, May 08, 2020 at 04:26:17PM -0700, Bart Van Assche wrote:
>> On 2020-05-04 19:09, Ming Lei wrote:
>>> @@ -391,6 +393,7 @@ struct blk_mq_ops {
>>> enum {
>>> BLK_MQ_F_SHOULD_MERGE = 1 << 0,
>>> BLK_MQ_F_TAG_SHARED = 1 << 1,
>>> + BLK_MQ_F_NO_MANAGED_IRQ = 1 << 2,
>>> BLK_MQ_F_BLOCKING = 1 << 5,
>>> BLK_MQ_F_NO_SCHED = 1 << 6,
>>> BLK_MQ_F_ALLOC_POLICY_START_BIT = 8,
>>> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
>>> index 77d70b633531..24b3a77810b6 100644
>>> --- a/include/linux/cpuhotplug.h
>>> +++ b/include/linux/cpuhotplug.h
>>> @@ -152,6 +152,7 @@ enum cpuhp_state {
>>> CPUHP_AP_SMPBOOT_THREADS,
>>> CPUHP_AP_X86_VDSO_VMA_ONLINE,
>>> CPUHP_AP_IRQ_AFFINITY_ONLINE,
>>> + CPUHP_AP_BLK_MQ_ONLINE,
>>> CPUHP_AP_ARM_MVEBU_SYNC_CLOCKS,
>>> CPUHP_AP_X86_INTEL_EPB_ONLINE,
>>> CPUHP_AP_PERF_ONLINE,
>>
>> Wouldn't BLK_MQ_F_NO_IRQ be a better name than BLK_MQ_F_NO_MANAGED_IRQ?
>
> No, what this patchset tries to do is to address request timeout or hang
> issue in case that managed irq is applied in blk-mq driver.
What is a managed IRQ? The following query did not produce a useful answer:
$ git grep -nHi managed.irq
Thanks,
Bart.
