From mboxrd@z Thu Jan 1 00:00:00 1970 From: venu_a@hyd.hellosoft.com (Venu A) Date: Fri, 16 Jan 2009 10:18:01 +0530 Subject: [ltt-dev] Interpreting tracing results - 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> Message-ID: <001b01c97795$9c552cf0$6401a8c0@avenu> Message-ID: <20090116044801.nhuYD3vuPqEtkjMZvCa11FJesg-ev8qHG3SGztC4Qns@z> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_arm_jiffiestsc_2_6_24.patch Type: application/octet-stream Size: 3570 bytes Desc: not available URL: