[ltt-dev] Bug in LTTv statistics ?

[François Godin]

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.

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?




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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100716/e446b908/attachment-0003.htm>