[ltt-dev] LTT for ARM

[Mathieu Desnoyers]

* Ali Günhan Akyürek (aliakyurek at gmail.com) wrote:
> Hi,
> 
> I've checked omap patch, and i'm trying to do something similar to it.
> 
> trace_clock_read32 of omap:
> static inline u32 trace_clock_read32(void)
> {
>     u32 val;
> 
>     isb();
>     val = read_ccnt();
>     isb();
>     return val;
> }
> 
> trace_clock_read32 of mine:
> static inline u32 trace_clock_read32(void)
> {
>     u32 val;
> 
>     /*isb();*/
>     val = DEV_MEM_READ_LE(SOCTIMER1_VAL_REG)
>     /*isb();*/
>     return val;
> }
> 
> 
> Sorry, It can be a dumb question, but my timer is 32-bits. Suppose the
> following case:
> trace_clock_read32 is called for a trace_mark and it returned 0xfffffff1 at
> second 3. In the same second 3, it's called again for the next
> trace_mark,and now returned 0x00000002
> So the second event occured later, but the clock value read at the second
> event is 0x00000002. How can LTTng understand the right order?,via an
> interrupt which is fired when timer is overflowed?

That's not a dumb question at all. It's actually a very important point
in LTTng timekeeping on architectures lacking a full 64-bit timer
register/mmio. It's handled by trace-clock-32-to-64 (code in
kernel/trace), which depends on a periodic timer interrupt to detect
overflows. The RCU-based algorithm is explained in my thesis:

http://www.lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf

Chapter 4, Paper 1: Synchronization for Fast and Reentrant Operating
System Kernel Tracing, section 4.6.3 Timekeeping.

Thanks,

Mathieu

> 
> Best regards,
> Ali
> 
> 
> 
> 
> On Wed, Mar 2, 2011 at 2:22 PM, Mathieu Desnoyers <
> compudj at krystal.dyndns.org> wrote:
> 
> > * Ali Günhan Akyürek (aliakyurek at gmail.com) wrote:
> > > Hi all,
> > >
> > > Two years ago, I've integrated LTTng to a device with ARM platform and
> > with
> > > kernel 2.6.22. LTTng version was 0.9.10.
> > > I used a sub-arch specific clock source for timestamps, based on the
> > > discussion below:
> > >
> > > http://lttng.org/pipermail/ltt-dev/2009-January/000771.html
> > >
> > > My sub-arch specific code in asm-arm/ltt.h was the following:
> > >
> > > +#ifndef _ASM_ARM_LTT_H
> > > +#define _ASM_ARM_LTT_H
> > > +
> > > +#include <linux/jiffies.h>
> > > +#include <linux/seqlock.h>
> > > +
> > > +#define LTT_ARCH_TYPE LTT_ARCH_TYPE_ARM
> > > +#define LTT_ARCH_VARIANT LTT_ARCH_VARIANT_NONE
> > > +
> > > +#define DEV_MEM_READ_LE(addr)  ((*((volatile unsigned int*)(addr))))
> > > +
> > > +#define SOCTIMER1_VAL_REG 0xF102031C
> > > +#define TIMER1_VAL ((0xffffffff - DEV_MEM_READ_LE(SOCTIMER1_VAL_REG)))
> > > +
> > > +#define TCLK_200MHZ    200000000
> > > +
> > > +u64 ltt_heartbeat_read_synthetic_tsc(void);
> > > +#undef LTT_HAS_TSC
> > > +
> > > +
> > > +static inline u32 ltt_get_timestamp32(void)
> > > +{
> > > +    return TIMER1_VAL;
> > > +}
> > > +
> > > +/* The shift overflow doesn't matter */
> > > +static inline u64 ltt_get_timestamp64(void)
> > > +{
> > > +    return ltt_heartbeat_read_synthetic_tsc();
> > > +}
> > > +
> > > +/* this has to be called with the write seqlock held */
> > > +static inline void ltt_reset_timestamp(void)
> > > +{
> > > +    //atomic_set(&lttng_logical_clock, 0);
> > > +}
> > > +
> > > +
> > > +static inline unsigned int ltt_frequency(void)
> > > +{
> > > +    return TCLK_200MHZ;    //number of timer ticks in a second.
> > > +}
> > > +
> > > +
> > > +static inline u32 ltt_freq_scale(void)
> > > +{
> > > +  return 1;
> > > +}
> > >
> > > This worked great for me at that time. However as today, I have to use
> > > kernel 2.6.31 and LTTng 0.178 on same device.
> > > Now, nor asm-arm/ltt.h, neither ltt_get_timestamp32 function exists. How
> > > must I proceed?
> > > Thanks in advance.
> >
> > The best way to understand the ARM trace clock is to look at the lttng
> > "development snapshot" patchset, which includes the LTTng trace clocks
> > patches all folded into about one patch per architecture. See
> >
> > http://lists.casi.polymtl.ca/pipermail/ltt-dev/2011-January/003751.html
> >
> > Once you see how the trace clock code works, and how to create your own
> > patch to add your own support, you can then move to the "lttng stable"
> > tree, which are still the versions you should use as an end user (until
> > we complete the current development phase).
> >
> > Thanks,
> >
> > Mathieu
> >
> > >
> > > Best regards,
> > > Ali
> >
> > > _______________________________________________
> > > ltt-dev mailing list
> > > ltt-dev at lists.casi.polymtl.ca
> > > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> >
> >
> > --
> > Mathieu Desnoyers
> > Operating System Efficiency R&D Consultant
> > EfficiOS Inc.
> > http://www.efficios.com
> >

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com