From mboxrd@z Thu Jan 1 00:00:00 1970 From: venu_a@hyd.hellosoft.com (Venu A) Date: Sat, 17 Jan 2009 10:38:53 +0530 Subject: [ltt-dev] jiffies TSC patch for 2.6.24 ARM 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> Message-ID: <002701c97861$b16cace0$6401a8c0@avenu> 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 ? 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)< 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.