Re: Experiences on ARM with LTTng

On Wed, 2007-09-12 at 13:31 -0400, Mathieu Desnoyers wrote:
> * Richard Purdie ([email protected]) wrote:
> I hope to finish that in 2 week to a month-ish before we have a LTTV
> matching with the current LTTng snapshot (without stack dump nor
> user-space tracing), but I see that interaction with LKML about patch
> integration often drives me away from the higher-level LTTng/LTTV effort
> :( Therefore, the process is slower, but at least we get things merged
> in mainline.

Yes, getting things merged with mainline is great to see and I fully
understand the competing priorities!

> > I ran into a couple of issues which I thought I'd mention here.
> > 
> > Firstly, it seems to be very easy to make LTTV segfault. Things I've
> > found that make it segfault include missing eventdefs directory,
> 
> This is going away..

Ok, I thought it might be.

> > missing
> > trace files and extra junk files in extra directories (e.g.
> > control/orig/interrupts_0).
> 
> This should be fixed.

ok.

> > In the latter case I had an extra file in
> > that location which was padded to the wrong size and I wouldn't have
> > expected LTTng to read it yet it did. 
> 
> Well, since the tracefiles created are not "fixed", we cannot specify a
> limited set of tracefiles for LTTV to read. Bogus tracefiles should not
> be in a trace at all in the first place ;) This approach is useful in
> many ways, including the fact that it helps dealing more easily with
> crash dump - flight recorder traces merge; one just has to create a
> crash/ subdirectory in its trace and put the buffers extracted from the
> crash dump there, along with the buffers that may also have been
> recorded while tracing was active.

I realise the bogus files shouldn't be there. Perhaps the best thing to
do would be to improve some of the error messages in tracefile.c so it
was obvious which tracefile was causing the problems and also consider
turning some of the asserts into "proper" errors complete with
filenames? If I'd been able to see which file was causing the problems I
would have realised what was going wrong much sooner...

> I guess the work would overlap a little bit. It would be better to do a
> pass on the code once I finish switching over to the markers.

Ok, that sounds sensible.

> I am a bit reluctant to use events to tell what happens with the TSC,
> since TSC is itself used to reorder events coming from multiple traces.
> I could be done, but goes against my motto about timekeeping: keep it
> simple. I would rather prefer an approach that would create a wrapper
> over the timestamp reads:
> 
> u64 sleep_cycles;
> 
> ltt_get_timestamp32()
>   - return (u32)(get_cycles() + sleep_cycles);
> 
> ltt_get_timestamp64()
>   - return get_cycles() + sleep_cycles;
> 
>  Called upon return from sleep mode:
> arch_ltt_add_timestamp()
>   - Updates sleep_cycles atomically
> 
> We would have to decide whether sleep_cycles should be per cpu.
> 
> What do you think of this approach ?

I've given it a bit of thought and I think it could work, my only
concern is how to handle incrementing sleep_cycles safely given its 64
bit.

My attention has been drawn to include/asm-arm/cnt32_to_63.h which
provides a lockless 32 to 63 bit conversion which may or may not help.

On the subject of whether it should be per cpu, on ARM I'd say there is
no need at present, I'm not sure if there are other places where it
would make sense...

Cheers,

Richard