[ltt-dev] Bug in LTTv statistics ?

[François Godin]

2010/7/16 Mathieu Desnoyers <compudj at krystal.dyndns.org>

> * François Godin (copelnug at gmail.com) wrote:
> > Thank for the answer. That made it clear but it bring others questions :
> >
> > Is the state for the "page_fault_entry" event is the previous state of
> the
> > cpu ? I suppose but a confirmation would be welcome.
>
> Well, in reality, the page fault entry event is recorded in page fault
> context. So the textdump has it right. But that's really just a
> "modeling artefact" to have one or the other.
>

Ok, but I need to know how the mode is found in LTTv stats to allow me to
compare two solutions. Then once I got it right, I can switch back to being
compatible with the textdump. Is my assumption correct ?


> >
> > I try to understand why on one trace, is there still "page_fault_entry"
> in
> > TRAP mode. I checked the previous correction, and while it find the right
> > states for all events except those that LTTv put in "TRAP" mode. Am I
> > missing something else or is it a glitch in LTTv?
>
> No sure what you mean. Can you try to explain a little more ?
>

I've made tests to verify my assumption. I load textdump in a custom parser
and it give me the mode of the "page_fault_entry" events. I then compare the
total of each mode to the number of "page_fault_entry" in each mode in the
statistics view. For one trace, the result was perfect but for another
trace, my parser didn't find any "page_fault_entry" events in the "TRAP"
mode like LTTv stats did. The others mode had the right total except one
whose total given by the parser was the one given by LTTv + the "page
fault_entry" in TRAP.

Page_fault_entry by mode:
LTTv    Parser
1          1          MODE_UNKNOWN
971      999       USER_MODE             999(parser) = 971(LTTv)
+28(LTTv-TRAP)
26        26         SYSCALL
28        0           TRAP


I've also made another discovery. It seems that the time between the
"page_fault_entry" or "page_fault_exit" and the previous event is never
added in the CPU_TIME. Is this intended?


>
> >
> >
> >
> >
> > 2010/7/15 Mathieu Desnoyers <compudj at krystal.dyndns.org>
> >
> > > * François Godin (copelnug at gmail.com) wrote:
> > > > I think I've found another bug in the LTTv statistics. The problem is
> > > with
> > > > page_fault_entry event. In the textdump they are classified as being
> in
> > > mode
> > > > TRAP but they appear in SYSCALL and USER_MODE mode in the statistics
> > > view.
> > >
> > > This comes from the way callbacks are dealt with in the priority hook
> > > list:
> > >
> > > When an event is encountered, the statistics "before" event callbacks
> > > are called first, then the state "before" event callbacks are called,
> > > then the event callbacks per se (e.g. textdump) are called, and then
> the
> > > after state, followed by after stats hooks.
> > >
> > > So given that the statistics hooks are called before the state
> > > modification, and that the textdump hooks are called after the state
> > > modification, there is a discrepancy between the two. But in reality,
> > > the statistic hook has the correct state associated (the trap occurs
> its
> > > calling context, not in "itself"). But how to fix the textdump is
> > > unclear to me.
> > >
> > > Thanks,
> > >
> > > Mathieu
> > >
> > > --
> > > Mathieu Desnoyers
> > > Operating System Efficiency R&D Consultant
> > > EfficiOS Inc.
> > > http://www.efficios.com
> > >
> >
> >
> >
> > --
> > François Godin
>
> --
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
>



-- 
François Godin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100716/e0947152/attachment-0003.htm>