lkml.org 
[lkml]   [2018]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/2] blk-mq: simplify queue mapping & schedule with each possisble CPU
    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

    \
     
     \ /
      Last update: 2018-01-26 10:32    [W:5.233 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site