• Daniel Bristot de Oliveira's avatar
    rtla/timerlat_aa: Fix previous IRQ delay for IRQs that happens after thread sample · 301deca0
    Daniel Bristot de Oliveira authored
    timerlat auto-analysis takes note of all IRQs, before or after the
    execution of the timerlat thread.
    
    Because we cannot go backward in the trace (we will fix it when
    moving to trace-cmd lib?), timerlat aa take note of the last IRQ
    execution in the waiting for the IRQ state, and then print it
    if it is executed after the expected timer IRQ starting time.
    
    After the thread sample, the timerlat starts recording the next IRQs as
    "previous" irq for the next occurrence.
    
    However, if an IRQ happens after the thread measurement but before the
    tracing stops, it is classified as a previous IRQ. That is not
    wrong, as it can be "previous" for the subsequent activation. What is
    wrong is considering it as a potential source for the last activation.
    
    Ignore the IRQ interference that happens after the IRQ starting time for
    now. A future improvement for timerlat can be either keeping a list of
    previous IRQ execution or using the trace-cmd library. Still, it requires
    further investigation - it is a new feature.
    
    Link: https://lore.kernel.org/lkml/a44a3f5c801dcc697bacf7325b65d4a5b0460537.1691162043.git.bristot@kernel.org
    
    Fixes: 27e348b2 ("rtla/timerlat: Add auto-analysis core")
    Signed-off-by: default avatarDaniel Bristot de Oliveira <bristot@kernel.org>
    301deca0
timerlat_aa.c 28.9 KB