[ltt-dev] Interpreting tracing results

[Mathieu Desnoyers]

* 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