Re: [linuxtools-dev] Modeled state in TMF/LTTng

[Mathieu Desnoyers <compudj@xxxxxxxxxxxxxxxxxx>]

* Francis Giraldeau (francis.giraldeau@xxxxxxxxxxxxxx) 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