[ltt-dev] Bug in LTTv statistics ?

[Mathieu Desnoyers]

* François Godin (copelnug at gmail.com) wrote:
> 2010/7/7 Mathieu Desnoyers <compudj at krystal.dyndns.org>
> 
> > * Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> > > * Copelnug (copelnug at gmail.com) wrote:
> > > > There seems to be a bug in the LTTv statistics.
> > > >
> > > > The problems is visible in the function "every_event" of the
> > lttv/stats.c
> > > > file. That function is called for each event and receive a
> > > > "LttvTracefileStats" structure as parameter.
> > > >
> > > > So if you check the value of the pointer to the "LttvTracefileStats"
> > > > received, you can see it changing between 15 and 20 value depending of
> > the
> > > > trace loaded. This seems to be intended to me because each type of
> > events is
> > > > associated with one and only one "LttvTracefileStats" (but a structure
> > can
> > > > have many events type).
> > > >
> > > > The bug seems to be a side effect : The structure passed to the
> > function
> > > > contain the current path to the "current_event_types_tree" that is used
> > to
> > > > increase the numbers of event for the event type. Or, this value is not
> > > > conserved between two "LttvTracefileStats" which means that the change
> > of
> > > > process or state only affect one "LttvTracefileStats" and let the
> > others to
> > > > their value. That means that some types of event are never affected by
> > a
> > > > change of mode or process.
> > > >
> > > > What this cause is :
> > > > - Many event in process 0 and Unknown mode.
> > > > - Difference between the total for a process of the event list in the
> > > > textdump and the value for the process in the statistics of the same
> > > > textdump.
> > > >
> > > > Is it really a problem or am I misunderstanding something ?
> > >
> > > Ack, I'm currently digging in the stats code to try to fix the problem.
> > > Thanks for the precise bug report.
> >
> > OK, very light testing seems to show that the fix I just did helps a
> > lot. Can you try the lttv version at the head of the git repo ?
> >
> > git clone git://lttng.org/lttv.git
> >
> > Then make sure you got my latest commit:
> >
> > cd lttv
> > git show 516a8712d079429962523e033e28f68704bc770a
> >
> > Please follow the quickstart guide for installation, in summary:
> >
> > ./autogen.sh --prefix=path_to_install CFLAGS=-g
> > make
> > make install
> >
> > I'll wait for your feedback before pushing a new release.
> >
> > Thanks,
> >
> > Mathieu
> >
> >
> I've tested it and the result are coherent between the event list of the
> textdump and the statistics given by it. So the fix is definitely working.

Great! :)

> 
> But, as I've looked in the event list of the textdump, I've seens something
> that could maybe trigger a bug. The core_marker_* events at the start where
> mixed with some other events. In this case, there were no sched_schedule,
> but it could maybe happen. So the questions are : Are all core_marker_*
> supposed to be unknown ?  Are the process_state suppose to trigger a change
> to process 0 ? Are all event between process the last process_state and the
> next sched_schedule suppose to be at process 0 ? And is this covered in the
> code  or impossible to happen ?

This is fine and expected. The state dump (and marker table dump) is
done concurrently with active tracing and the viewer must handle that.
For the marker table, we iterate on the metadata channel before doing
anything else with the trace, so we get specifically all the metadata
events.

Thanks,

Mathieu

> 
> 
> -- 
> François Godin

> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com