* Ali Günhan Akyürek ([email protected]) 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 < > [email protected]> wrote: > > > * Ali Günhan Akyürek ([email protected]) 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(<tng_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 > > > [email protected] > > > 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
