* [ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM
2009-01-16 4:48 ` [ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM Venu A
@ 2009-01-16 4:48 ` Venu A
2009-01-16 4:48 ` Venu A
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Venu A @ 2009-01-16 4:48 UTC (permalink / raw)
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 <executable_name>. 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 <linux/smp.h>
#include <linux/sched.h> /* 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 <linux/param.h> /* For HZ */
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/arch/io.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/platform.h>
+#include <asm/hardware/arm_timer.h>
+#include <asm/hardware/vic.h>
+
+#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)<<ovr) -
(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" <compudj@krystal.dyndns.org>
To: "Akyurek, Ali (EXT)" <ali.akyurek.ext at siemens.com>
Cc: <ltt-dev at lists.casi.polymtl.ca>; "Venu A" <venu_a at hyd.hellosoft.com>
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: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20090116/5b861681/attachment.obj>
^ permalink raw reply [flat|nested] 11+ messages in thread* [ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM
2009-01-16 4:48 ` [ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM Venu A
2009-01-16 4:48 ` Venu A
@ 2009-01-16 4:48 ` Venu A
[not found] ` <1E65288790442545B413D69F2A8D27DE045EC0ED@ERLD164A.ww004.siemens.net>
2009-01-28 17:05 ` [ltt-dev] Maybe an answer to your question -application thread calling gettimeofday in a loop- Akyurek, Ali (EXT)
3 siblings, 0 replies; 11+ messages in thread
From: Venu A @ 2009-01-16 4:48 UTC (permalink / raw)
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 <executable_name>. 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 <linux/smp.h>
#include <linux/sched.h> /* 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 <linux/param.h> /* For HZ */
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/arch/io.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/platform.h>
+#include <asm/hardware/arm_timer.h>
+#include <asm/hardware/vic.h>
+
+#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)<<ovr) -
(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" <compudj@krystal.dyndns.org>
To: "Akyurek, Ali (EXT)" <ali.akyurek.ext at siemens.com>
Cc: <ltt-dev at lists.casi.polymtl.ca>; "Venu A" <venu_a at hyd.hellosoft.com>
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: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20090116/5b861681/attachment-0002.obj>
^ permalink raw reply [flat|nested] 11+ messages in thread[parent not found: <1E65288790442545B413D69F2A8D27DE045EC0ED@ERLD164A.ww004.siemens.net>]
* [ltt-dev] jiffies TSC patch for 2.6.24 ARM
[not found] ` <1E65288790442545B413D69F2A8D27DE045EC0ED@ERLD164A.ww004.siemens.net>
@ 2009-01-17 5:08 ` Venu A
2009-01-20 2:58 ` Mathieu Desnoyers
0 siblings, 1 reply; 11+ messages in thread
From: Venu A @ 2009-01-17 5:08 UTC (permalink / raw)
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)" <ali.akyurek.ext@siemens.com>
To: "Venu A" <venu_a at hyd.hellosoft.com>
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 <executable_name>. 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 <linux/smp.h>
#include <linux/sched.h> /* 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 <linux/param.h> /* For HZ */
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/arch/io.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/platform.h>
+#include <asm/hardware/arm_timer.h>
+#include <asm/hardware/vic.h>
+
+#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)<<ovr) -
(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" <compudj@krystal.dyndns.org>
To: "Akyurek, Ali (EXT)" <ali.akyurek.ext at siemens.com>
Cc: <ltt-dev at lists.casi.polymtl.ca>; "Venu A" <venu_a at hyd.hellosoft.com>
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* [ltt-dev] jiffies TSC patch for 2.6.24 ARM
2009-01-17 5:08 ` [ltt-dev] " Venu A
@ 2009-01-20 2:58 ` Mathieu Desnoyers
0 siblings, 0 replies; 11+ messages in thread
From: Mathieu Desnoyers @ 2009-01-20 2:58 UTC (permalink / raw)
* 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)"
> <ali.akyurek.ext at siemens.com>
> To: "Venu A" <venu_a at hyd.hellosoft.com>
> 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 <executable_name>. 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 <linux/smp.h>
> #include <linux/sched.h> /* 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 <linux/param.h> /* For HZ */
> +#include <asm/atomic.h>
> +#include <asm/io.h>
> +#include <asm/arch/io.h>
> +#include <asm/arch/hardware.h>
> +#include <asm/arch/platform.h>
> +#include <asm/hardware/arm_timer.h>
> +#include <asm/hardware/vic.h>
> +
> +#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)<<ovr) -
> (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"
> <compudj at krystal.dyndns.org>
> To: "Akyurek, Ali (EXT)" <ali.akyurek.ext at siemens.com>
> Cc: <ltt-dev at lists.casi.polymtl.ca>; "Venu A" <venu_a at hyd.hellosoft.com>
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [ltt-dev] Maybe an answer to your question -application thread calling gettimeofday in a loop-
2009-01-16 4:48 ` [ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM Venu A
` (2 preceding siblings ...)
[not found] ` <1E65288790442545B413D69F2A8D27DE045EC0ED@ERLD164A.ww004.siemens.net>
@ 2009-01-28 17:05 ` Akyurek, Ali (EXT)
3 siblings, 0 replies; 11+ messages in thread
From: Akyurek, Ali (EXT) @ 2009-01-28 17:05 UTC (permalink / raw)
Hi Venu,
I remembered your below message, when i've faced a similar question. Perhaps you've found a solution.
If you are using shared libraries with your application, you should be able find it there.
/proc/your_app_id/maps shows where the shared libraries reside in your application mapping. Then you can find the right shared lib.
Then nm shared_lib will do the work.
Best regards
Ali
-----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 <executable_name>. 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 <linux/smp.h>
#include <linux/sched.h> /* 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 <linux/param.h> /* For HZ */
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/arch/io.h>
+#include <asm/arch/hardware.h>
+#include <asm/arch/platform.h>
+#include <asm/hardware/arm_timer.h>
+#include <asm/hardware/vic.h>
+
+#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)<<ovr) -
(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" <compudj@krystal.dyndns.org>
To: "Akyurek, Ali (EXT)" <ali.akyurek.ext at siemens.com>
Cc: <ltt-dev at lists.casi.polymtl.ca>; "Venu A" <venu_a at hyd.hellosoft.com>
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.
^ permalink raw reply [flat|nested] 11+ messages in thread