[ltt-dev] Interpreting tracing results - jiffies TSC patch for 2.6.24 ARM
Venu A
venu_a at hyd.hellosoft.com
Thu Jan 15 23:48:01 EST 2009
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.
-------------- 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-0003.obj>
More information about the lttng-dev
mailing list