[ltt-dev] jiffies TSC patch for 2.6.24 ARM

Mon Jan 19 21:58:24 EST 2009

* 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(&lttng_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(&lttng_clock);
> +       new_clock = (old_clock
> +TICKS_PER_uS*(((TMR_INTERVAL)<<1)-(readl(JIFFIES_VA_BASE + 
> TIMER_VALUE))));
> +   } while (atomic_cmpxchg(&lttng_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