Hi Jianchao, On Fri, Jan 19, 2018 at 11:05:35AM +0800, jianchao.wang wrote: > Hi ming > > Sorry for delayed report this. > > On 01/17/2018 05:57 PM, Ming Lei wrote: > > 2) hctx->next_cpu can become offline from online before __blk_mq_run_hw_queue > > is run, there isn't warning, but once the IO is submitted to hardware, > > after it is completed, how does the HBA/hw queue notify CPU since CPUs > > assigned to this hw queue(irq vector) are offline? blk-mq's timeout > > handler may cover that, but looks too tricky. > > In theory, the irq affinity will be migrated to other cpu. This is done by Yes, but the other CPU should belong to this irq's affinity, and if all CPUs in the irq's affinity is DEAD, this irq vector will be shutdown, and if there is in-flight IO or will be, then the completion for this IOs won't be delivered to CPUs. And now seems we depend on queue's timeout handler to handle them. > fixup_irqs() in the context of stop_machine. > However, in my test, I found this log: > > [ 267.161043] do_IRQ: 7.33 No irq handler for vector > > The 33 is the vector used by nvme cq. > The irq seems to be missed and sometimes IO hang occurred. As I mentioned above, it shouldn't be strange to see in CPU offline/online stress test. -- Ming