* Francis Giraldeau (francis.girald...@usherbrooke.ca) wrote: > On Fri, 2011-01-07 at 22:01 -0500, Alexandre Montplaisir wrote: > > On 11-01-07 05:50 PM, Michel Dagenais wrote: > > > The Multi-Core Association is working on a Trace Format Standard. While > > > they are looking at metadata describing the events (type of events, the > > > type of their fields...), the idea has been proposed to also document the > > > associated "modeled state". > > > > I think this is the way to go. Right now the "state updating" > > mechanisms, which convert events in the trace to state changes, reside > > in the viewers (in state.c for LTTV, and StateUpdateHandlers.java for > > TMF). This means that if we add or modify existing tracepoints in LTTng, > > the viewers have to be updated as well. > > The problem is that the same event can change the state of multiple > state machines. In lttv, a state is held for CPUs and process.
It's not because the current LTTV state machines differ for cpu state and thread state that this is the correct model. The CPU state machine has been added by Pierre-Marc rather separately from the per-thread state machine. The appropriate way to integrate all this might have rather been to integrate both state machines together. > Some > people are using raw events to generate higher level state machine of > the system. I did my own state machine for analysis from only events I > needed. But in this case, it's a problem-specific state machine to detect a particular condition/pattern. What we're trying to find out here is if there is value in describing a state machine directly within the instrumentation metadata, so we can have a basic model that describes the traced system. If we think of the trace data as compressed at generation-time by only saving the state machine changes into the trace records, it makes sense to represent this state machine as part of the metadata to allow automatic "decompression" of the trace data. Now, specific analysis are of course valuable too, but if they are not required to "decompress" the trace state, then they should probably be left out as specific analysis plugins (which can produce their own state machines). It could be interesting to re-use the same format to describe these state machine plugins though, and using the format I proposed for the metadata might be a good idea. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
