[ltt-dev] trace_clock_update() spinning
mmcternan at airvana.com
Tue Feb 2 13:52:52 EST 2010
I'm using Linux 184.108.40.206 + 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;
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)
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?
More information about the lttng-dev