[ltt-dev] trace_clock_update() spinning

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

Hi Mike,

The answer to your question is in the LTTng Manual, "Supported
architectures"

http://lttng.org/cgi-bin/gitweb.cgi?p=lttv.git;a=blob_plain;f=LTTngManual.html

it states that "Other ARM (with limited timestamping precision, e.g.
1HZ. Need architecture-specific support for better precision)"

So it's not that LTTng itself is taking time, but that the trace clock
resolution available for your architecture is really coarse. You could
possibly get a better resolution by creating a trace clock specific for
your architecture.

Mathieu

* Mike McTernan (mmcternan at airvana.com) wrote:
> Hi,
> 
> I'm using Linux 2.6.28.2 + LTTng 0.88 on an ARM Freescale i.MX51 board.
> 
> 
> The system works quite well - in fact LTTng is awesome!  But there's a
> problem that the output in LTTV shows run_timer_softirq() taking almost
> all the time between timer ticks.  HZ is set to 100 so the timer IRQ
> runs every 10ms, with run_timer_softirq() typically taking about 9.8ms
> as measured in LTTV.
> 
> I added some trace_mark() calls to find the consumer of this time to be
> trace_clock_update().  Specifically the atomic update:
> 
>   n = 0;
>   
>   do {
>     n++;
>     
>     old_clock = atomic_long_read(&trace_clock);
>     new_clock = (old_clock + (ticks << TRACE_CLOCK_SHIFT))
>       & (~((1 << TRACE_CLOCK_SHIFT) - 1));             
>   } while (atomic_long_cmpxchg(&trace_clock, old_clock, new_clock)
>              != old_clock);
> 
>   trace_mark(trace_clock_update, exit, "exit %u", n);
> 
> This never appears to loop as the "exit" value I added is always 1.
> However I notice that on ARM atomic_long_cmpxchg() contains a loop, and
> so is presumably racing around in there.
> 
> I'm not sure if this something completely unexpected, or normal
> behaviour?  Looking through the code I can't see that trace_clock is
> updated in many cases, although my grep maybe off.  I wondered if the
> ARM atomic_long_cmpxchg() is broken, but didn't find much there either.
> 
> Since I'm on a uniprocessor system, could I safely modify the update
> function to just atomically update the trace_clock without using the
> cmpxchg() operation since it's called in the soft IRQ?
>  
> Regards,
> 
> Mike
> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

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