[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Mathieu Desnoyers]

* Trilok Soni (soni.trilok at gmail.com) wrote:
> Hi,
> 
> I would like to try LTTng to measure the keypad and touchscreen
> drivers events latency on ARM based board, which typically runs less
> than 1GHz frequency.  I have recently tried LTTng patches as per
> compatibility list on LTTng website on 2.6.25 kernel on ARM11 based
> board, but on LTTv it shows the IRQ min/max interval times on
> nanoseconds precision, would that be correct? Because I thought it
> could be possible to microseconds format until with hrtimers support
> right? Just guide so that I can use this tool to effectively measure
> driver latencies. Thanks.
> 

Hi Trilok,

The current Trace Clock implementation uses the generic fallback in
include/asm-generic/trace-clock.h as a time source on ARM. It has a 1
jiffy precision and uses a logical clock in the least significant bits,
incremented a each event, to keep track of the event order. Therefore,
you should not rely on timing information more precise than 1 HZ.

However, I wonder if some of the newer ARM boards would happen to have a
cycle counter (timestamp counter), so we could implement a get_cycles()
and trace clock for them ?

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Russell King]

On Mon, Dec 01, 2008 at 05:35:02AM -0500, Mathieu Desnoyers wrote:
> However, I wonder if some of the newer ARM boards would happen to have a
> cycle counter (timestamp counter), so we could implement a get_cycles()
> and trace clock for them ?

There continues to be nothing architected for that - it would be very
SoC specific and the precision and resolution is very variable if it's
provided at all.  About the best implementation is a 32-bit counter
being clocked at various rates depending on the implementation.

Our best implementation is used for sched_clock() with all the
cnt32_to_63() stuff to extend the size of the counter which as we've
seen from other threads, may cause problems if used for other purposes.

The next best implementation is probably the hrtimer stuff.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Mathieu Desnoyers]

* Russell King (rmk+lkml at arm.linux.org.uk) wrote:
> On Mon, Dec 01, 2008 at 05:35:02AM -0500, Mathieu Desnoyers wrote:
> > However, I wonder if some of the newer ARM boards would happen to have a
> > cycle counter (timestamp counter), so we could implement a get_cycles()
> > and trace clock for them ?
> 
> There continues to be nothing architected for that - it would be very
> SoC specific and the precision and resolution is very variable if it's
> provided at all.  About the best implementation is a 32-bit counter
> being clocked at various rates depending on the implementation.
> 
> Our best implementation is used for sched_clock() with all the
> cnt32_to_63() stuff to extend the size of the counter which as we've
> seen from other threads, may cause problems if used for other purposes.
> 
> The next best implementation is probably the hrtimer stuff.
> 

Ok, so for LTTng on ARM it would make sense to use the same clock source
as sched_clock for :
mach-pxa, mach-realview, mach-sa1100, mach-versatile, plat-omap.

We basically have, for each of these build scenarios, to take the mmio
clock used by sched_clock and use it through
kernel/trace/trace-clock-32-to-64 to extend it to 64-bits. Therefore we
won't suffer from any of the constrains linked to cnt32_to_63 and we
would be sure that the trace clock is correct wrt SMP wrt memory
barriers and cache line bouncing because it uses per-cpu data to keep
the counters.

That should be pretty much straightforward to do. Basically starting
from the MIPS trace clock I already have should make it trivial.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Russell King]

On Mon, Dec 01, 2008 at 05:57:37AM -0500, Mathieu Desnoyers wrote:
> Ok, so for LTTng on ARM it would make sense to use the same clock source
> as sched_clock for :
> mach-pxa, mach-realview, mach-sa1100, mach-versatile, plat-omap.
> 
> We basically have, for each of these build scenarios, to take the mmio
> clock used by sched_clock and use it through
> kernel/trace/trace-clock-32-to-64 to extend it to 64-bits. Therefore we
> won't suffer from any of the constrains linked to cnt32_to_63 and we
> would be sure that the trace clock is correct wrt SMP wrt memory
> barriers and cache line bouncing because it uses per-cpu data to keep
> the counters.

Just remember that MMIO clock sources are not available until after
setup_arch() has finished - in other words, they don't work when the
kernel initially boots.  Accessing them too early will cause a page
fault and hang the kernel.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

[ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

[Mathieu Desnoyers]

* Russell King (rmk+lkml at arm.linux.org.uk) wrote:
> On Mon, Dec 01, 2008 at 05:57:37AM -0500, Mathieu Desnoyers wrote:
> > Ok, so for LTTng on ARM it would make sense to use the same clock source
> > as sched_clock for :
> > mach-pxa, mach-realview, mach-sa1100, mach-versatile, plat-omap.
> > 
> > We basically have, for each of these build scenarios, to take the mmio
> > clock used by sched_clock and use it through
> > kernel/trace/trace-clock-32-to-64 to extend it to 64-bits. Therefore we
> > won't suffer from any of the constrains linked to cnt32_to_63 and we
> > would be sure that the trace clock is correct wrt SMP wrt memory
> > barriers and cache line bouncing because it uses per-cpu data to keep
> > the counters.
> 
> Just remember that MMIO clock sources are not available until after
> setup_arch() has finished - in other words, they don't work when the
> kernel initially boots.  Accessing them too early will cause a page
> fault and hang the kernel.
> 

This can be dealt with by refusing the get_trace_clock(), which should
probably be allowed to fail if the underlying infrastructure is not
ready when the trace buffers are created. The tracer would therefore not
accept to start any sort of tracing too soon for the architecture being
used.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68