[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] Interrupt latency measurement technique
Hi Ian On Thu, Aug 28, 2014 at 4:07 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |