[ltt-dev] Maybe an answer to your question -application thread calling gettimeofday in a loop-
Akyurek, Ali (EXT)
ali.akyurek.ext at siemens.com
Wed Jan 28 12:05:12 EST 2009
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 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.
More information about the lttng-dev
mailing list