If one doesn''t care about the performance overhead one could just read
the cycle counters when disabling/enabling interupts. Except, of
course, one would also need to account for the time when interrupts
are implicitly disabled due to exceptions, traps, incoming interrupts,
etc.
--text follows this line--
A better option would be to use the x86 performance counter which can
measure the number of cycles when interrupts are disabled. Read and
reset the counter whenever interrupts are enabled. Remember to
account for implicit interrupt enabling due to irets as well.
A more performant solution is to do some more clever tricks by
trapping on performance counter overflows. Instead of reading the
counter each time interrupts are enabled simply reset it instead.
When overflows occur adjust the reset value until overflows stop
occuring. If the overflow interrupt is configured as non-NMI you can
even read the current counter value to determing how much the counter
overflowed by. The reset value which does not produce overflows gives
you the maximum, slightly pessimitic, interrupt latency.
Never tried any of these approaches, but they should in theory work.
eSk
[Dan Magenheimer]> Has anyone measured interrupt latency in Xen? By interrupt latency,
> I specifically mean the longest period of time interrupts are
> disabled.
>
> Some recent traffic makes me wonder how bad it is, and if it has
> improved between 3.2 and 4.0.
>
> If not, any ideas on how to measure it? I found this
>
> http://www.ganssle.com/articles/interruptlatency.htm
>
> which suggests a good approach using timers, but am unsure as to if
> it would work for Xen and whether it would give decent granularity.
>
> (And with the new academic year starting soon, this might make a
> good term project for a student...)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel