Re: [RFC] Interrupt latency measurement technique

[Andrii Tseglytskyi <andrii.tseglytskyi@globallogic.com>]

Hi Ian

On Thu, Aug 28, 2014 at 4:07 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Wed, 2014-08-27 at 12:14 +0300, Andrii Tseglytskyi wrote:
>> Hi,
>>
>> I need to measure IRQ latency introduced by Xen: (GIC -> Xen IRQ
>> handler -> Dom0 IRQ handler)
>> I need to know how many time I spend in Xen IRQ handler.
>>
>> Can someone comment - is the following algorithm works:
>>
>> - in function xen/arch/arm/gic.c: gic_interrupt() store timer counter value:
>> xen_timer_val = READ_SYSREG64(CNTPCT_EL0) - READ_SYSREG64(CNTVOFF_EL2)
>>
>> - in any IRQ handler in dom0 store timer counter value:
>> dom0_timer_val = READ_SYSREG64(CNTPCT_EL0)
>>
>> - calculate time diff in nanoseconds:
>> time_diff_ns = ticks_to_ns(dom0_timer_val - xen_timer_val)
>>
>> Using this technique I measured display IRQ latency and got about
>> - 20 to 30 usec latency on 1 GHz MPU frequency
>> - 10 to 20 usec latencyon 1.5 GHz MPU frequency
>>
>> Are these numbers expectable?
>
> How do they compare to just native Linux?
>

Never measured native Linux. I just need to measure overhead, introduced by Xen.
So I take a time difference between git_interrupt() in Xen and
gic_interrupt() in Linux


> One thing to watch out for is the virtualised offset of dom0's timer, I
> can't remember if this is expected to be zero or non-zero, if the latter
> then you will need to subtract it out.
>

Yes, I do READ_SYSREG64(CNTVOFF_EL2), it is virtualized offset of dom0
timer, and it is not zero, always

>>  Can this technique be used?
>
> One thing which it misses is the time from the IRQ line going high to
> reaching gic_interrupt. I don't know if that is a concern for you.
>

I know. But the only way to measure above gic_interrupt() call is an
oscilloscope measurement, You already mentioned it below.

> Not sure what embedded folks usually do here (you probably know better
> than me). One technique I've heard of is to inject an interrupt via an
> external GPIO input and toggle another GPIO in response, then you can
> use a scope to observe the difference.

Yes. This is the most precise method. But I'm looking for pure software method.

Thank you for your comments,

Regards,
Andrii

>
> Ian.
>



-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com