From mboxrd@z Thu Jan 1 00:00:00 1970 From: compudj@krystal.dyndns.org (Mathieu Desnoyers) Date: Mon, 19 Jan 2009 21:58:24 -0500 Subject: [ltt-dev] jiffies TSC patch for 2.6.24 ARM In-Reply-To: <002701c97861$b16cace0$6401a8c0@avenu> References: <1E65288790442545B413D69F2A8D27DE045EBBC4@ERLD164A.ww004.siemens.net> <20090115151855.GA27345@Krystal> <1E65288790442545B413D69F2A8D27DE045EBC7B@ERLD164A.ww004.siemens.net> <20090115175339.GA31571@Krystal> <1E65288790442545B413D69F2A8D27DE045EBC84@ERLD164A.ww004.siemens.net> <20090115182041.GA32620@Krystal> <001b01c97795$9c552cf0$6401a8c0@avenu> <1E65288790442545B413D69F2A8D27DE045EC0ED@ERLD164A.ww004.siemens.net> <002701c97861$b16cace0$6401a8c0@avenu> Message-ID: <20090120025824.GA12024@Krystal> * Venu A (venu_a at hyd.hellosoft.com) wrote: > Hi > The hardware timer is in the SoC and is used by the operating system for > generating an interrupt every jiffy (10ms). Hence this timer would be > already configured in (hopefully) every linux platform as a part of the > platform porting process. > We do not need to configure the timer hardware for LTT TSC purpose, and > only need to be aware of the timer configuration such as timer reload > value, timer interval in ms, clock divider etc. > Also since your crystal is 32768 Hz, the best resolution in timestamp you > would get is roughly 30 microsecond. > > Mathieu, > On a related note, if two events have the same timestamp (due to say, 30 > microsecond resolution) how does the LTT viewer handle it ? What does it > display the event order as ? Are both the events visible in LTT viewer ? > They will appear in the text dump in a random order and the graphical view will behave as if they occured at the exact same time on the CPU, which means that some lines may have 0-pixel length, which is not exactly good.... Mathieu > regards > Venu Annamraju > Team Lead, VoIP-DSP > HelloSoft India > > > ----- Original Message ----- From: "Akyurek, Ali (EXT)" > > To: "Venu A" > Sent: Friday, January 16, 2009 6:34 PM > Subject: AW: jiffies TSC patch for 2.6.24 ARM > > > > Hi Mr. Annamraju, > I have a question about the jiffies hardware timer. > Is it in the SOC? How it is decremented or incremented? By which clock? > > > -----Urspr?ngliche Nachricht----- > Von: Venu A [mailto:venu_a at hyd.hellosoft.com] > Gesendet: Freitag, 16. Januar 2009 05:48 > An: Mathieu Desnoyers; Akyurek, Ali (EXT) > Cc: ltt-dev at lists.casi.polymtl.ca > Betreff: Re: AW: AW: [ltt-dev] Interpreting tracing results - jiffies TSC > patch for 2.6.24 ARM > > Hi > > Please find the attached patch for 2.6.24 kernel that uses the jiffies > hardware timer for LTT timestamping. Please note the implementation is > specific for a platform. > I find the integration in 2.6.24 is more straight forward compared to > 2.6.21. > > Could someone answer below query: > I see an application thread calling gettimeofday in a loop, though there is > no explicit code doing that. How do I map the system call address in the > trace to a function which is either in kernel or user application. I could > not find the address anywhere in System.map of kernel or in the application > map file. To obtain the > application map file I invoke #nm . Am I missing > something > ? > > regards > Venu Annamraju > Team Lead, VoIP-DSP > HelloSoft India > ============================================================================= > --- ltt/Kconfig 2009-01-10 17:19:36.000000000 +0530 > +++ ltt/Kconfig 2009-01-10 17:21:23.000000000 +0530 > @@ -10,12 +10,10 @@ > def_bool n > > config HAVE_LTT_CLOCK > - def_bool n > + def_bool y > > config HAVE_LTT_SYNTHETIC_TSC > - bool > - default y if (!HAVE_LTT_CLOCK) > - default n if HAVE_LTT_CLOCK > + def_bool y > > config HAVE_LTT_DUMP_TABLES > def_bool n > > --- ltt/ltt-timestamp.c.old 2009-01-10 17:57:53.000000000 +0530 > +++ ltt/ltt-timestamp.c 2009-01-10 18:04:45.000000000 +0530 > @@ -24,7 +24,7 @@ > #include > #include /* FIX for m68k local_irq_enable in on_each_cpu */ > > -atomic_t lttng_generic_clock; > +atomic_t lttng_generic_clock = ATOMIC_INIT(0); > EXPORT_SYMBOL(lttng_generic_clock); > > /* Expected maximum interrupt latency in ms : 15ms, *2 for security */ > > --- /dev/null 2008-07-14 17:17:21.160348368 +0530 > +++ include/asm/ltt.h 2009-01-10 19:41:27.000000000 +0530 > @@ -0,0 +1,76 @@ > +#ifndef _ASM_ARM_LTT_H > +#define _ASM_ARM_LTT_H > + > +/* > + * linux/include/asm-arm/ltt.h > + * > + * Copyright (C) 2007 - Mathieu Desnoyers (mathieu.desnoyers at polymtl.ca) > + * > + * Copyright (C) 2009 - Venu Annamraju (venu_a at hyd.hellosoft.com) > + * Generic definitions for LTT modified for ARM platform > + * Architectures with Hardware Timer > + */ > + > +#include /* For HZ */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define __io_address(n) __io(IO_ADDRESS(n)) > +#define VIC_BASE (0xfefff000) > +#define JIFFIES_VA_BASE (__io_address(HS1XX_TMR0_BASE)) > +#define VADDR_VIC_BASE ( __io(VIC_BASE)) > +#define TICKS_PER_uS (1) //Timer ticks in 1 microsecond for a > 1MHz > clock with no division, is 1. For higher precision timers it may be higher. > +#define TMR_INTERVAL (TICKS_PER_uS * 10000) // jiffies timer > fires > every 10ms. So the timer interval in terms of ticks is 10000. > + > + > +u64 ltt_read_synthetic_tsc(void); > + > +extern atomic_t lttng_generic_clock; > + > +#define lttng_clock lttng_generic_clock > + > +static inline u32 ltt_get_timestamp32(void) > +{ > + int tmp_clk, status,ovr=0; > + /* this interrupt check is useful in providing a smooth continuous > timer out of the jiffies timer. > + In an event where the timer interrupt is waiting because we are in an > NMI or entry of timer IRQ handler, the timer reg would have wrapped around. > + Obtaining a timestamp at that instance will show negative time. > + This check increment add a jiffy if Timer Interrupt is waiting when > ltt_get_timestamp32 is called */ > + status = __raw_readl(VADDR_VIC_BASE + VIC_RAW_STATUS); > + if (status & INTMASK_TMR0) > + { > + ovr = 1; > + } > + tmp_clk = atomic_read(<tng_clock); > + return (tmp_clk + TICKS_PER_uS*(((TMR_INTERVAL)< (readl(JIFFIES_VA_BASE + TIMER_VALUE)))); > +} > + > +static inline u64 ltt_get_timestamp64(void) > +{ > + return ltt_read_synthetic_tsc(); > +} > + > +static inline void ltt_add_timestamp(unsigned long ticks) > +{ > + int old_clock, new_clock; > + do { > + old_clock = atomic_read(<tng_clock); > + new_clock = (old_clock > +TICKS_PER_uS*(((TMR_INTERVAL)<<1)-(readl(JIFFIES_VA_BASE + > TIMER_VALUE)))); > + } while (atomic_cmpxchg(<tng_clock, old_clock, new_clock) > !=old_clock); > +} > + > +static inline unsigned int ltt_frequency(void) > +{ > + return HZ*TMR_INTERVAL*TICKS_PER_uS; //number of timer ticks in a > second. > +} > + > +static inline u32 ltt_freq_scale(void) > +{ > + return 1; > +} > +#endif /* _ASM_ARM_LTT_H */ > > > ============================================================================= > > ----- Original Message ----- From: "Mathieu Desnoyers" > > To: "Akyurek, Ali (EXT)" > Cc: ; "Venu A" > Sent: Thursday, January 15, 2009 11:50 PM > Subject: Re: AW: AW: [ltt-dev] Interpreting tracing results > > > * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: >> >> Thanks Mathieu, >> > > Yes, if it is set to have its counter running at that speed. > > You will probably find this post interesting. I have not had the time to > review this patch yet. > > http://lists.casi.polymtl.ca/pipermail/ltt-dev/2009-January/000638.html > > Mathieu > >> What i am gonna say now, may completely not make sense. But; >> Can i implement a more precise trace-clock for my board using its RTC? >> Since it is 32.768kHz. >> >> Best regards, >> >> Ali >> >> >> -----Urspr?ngliche Nachricht----- >> Von: Mathieu Desnoyers [mailto:compudj at krystal.dyndns.org] >> Gesendet: Donnerstag, 15. Januar 2009 18:54 >> An: Akyurek, Ali (EXT) >> Cc: ltt-dev at lists.casi.polymtl.ca >> Betreff: Re: AW: [ltt-dev] Interpreting tracing results >> >> * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: >> > >> > Hi >> > >> > So, it means that calculating a context switching time in arm is not >> > sensible for now,huh? >> > Because i found that 1220 ns. >> > >> > And 1220 ns is just = [1 / (HZ << TRACE_CLOCK_SHIFT)]. >> > >> > // HZ is 100 in my system, and trace_clock_shift is 13 >> > >> >> Exactly. You cannot expect that kind of precision on ARM currently >> without implementing a more precise trace-clock suited for your >> sub-architecture, possibly based on a free timer. >> >> Mathieu >> >> > Thanks. >> > >> > >> > -----Urspr?ngliche Nachricht----- >> > Von: Mathieu Desnoyers [mailto:compudj at krystal.dyndns.org] >> > Gesendet: Donnerstag, 15. Januar 2009 16:19 >> > An: Akyurek, Ali (EXT) >> > Cc: ltt-dev at lists.casi.polymtl.ca >> > Betreff: Re: [ltt-dev] Interpreting tracing results >> > >> > * Akyurek, Ali (EXT) (ali.akyurek.ext at siemens.com) wrote: >> > > >> > > Hi all, >> > > >> > > In my arm machine, context switching takes 1220 or 1221 nanoseconds. >> > > i thought this time as (start of sched_schedule - start of >> > > whatever_previous_event), Actually that is the time between different >> > > PID values in rows.am i right? >> > > >> > > and >> > > >> > > Handling of interrupts (i take only the top handlers, not soft ones.) >> > > takes 2441 nanoseconds. >> > > i thought this time as (end of irq_exit - start of irq_entry), am i >> > > right? >> > > >> > > Why are these values multiple of 1220 nanoseconds? What is related to? >> > > >> > >> > Hi, >> > >> > LTTng uses the generic trace clock for ARM by default. See >> > include/asm-generic/trace-clock.h. >> > >> > This clock has only the precision of HZ frequency, and I use an atomic >> > counter in the LSBs to keep the events ordered. >> > >> > Please have a look at the ARM-related messages in the past 2 weeks for >> > implementations of sub-arch specific clock sources for ARM. I will >> > integrate this kind of work soon after making sure it's smp-safe when it >> > needs to. >> > >> > Mathieu >> > >> > > Thanks all. >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> -- >> Mathieu Desnoyers >> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE >> 9A68 >> > > -- > Mathieu Desnoyers > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 > > The information contained in this e-mail message and/or attachments to it > may > contain confidential or privileged information. If you are not the intended > recipient, any dissemination, use, review, distribution, printing or > copying of the information contained in this e-mail message and/or > attachments to it are strictly prohibited. If you have received this > communication in error, please notify us by reply e-mail immediately and > permanently delete the message and any attachments. > > > The information contained in this e-mail message and/or attachments to it > may > contain confidential or privileged information. If you are not the intended > recipient, any dissemination, use, review, distribution, printing or > copying of the information contained in this e-mail message and/or > attachments to it are strictly prohibited. If you have received this > communication in error, please notify us by reply e-mail immediately and > permanently delete the message and any attachments. > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68