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 <[email protected]> > * François Godin ([email protected]) 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
_______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
