[ltt-dev] trace_clock_update() spinning

[Mike McTernan]

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