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

["Oestman, Fredrik" <Fredrik_Oestman@xxxxxxxxxx>]

Michel Dagenais [michel.dagenais@xxxxxxxxxx] wrote:
> -> proposed term: "modeled state", simple abstract model of a complex application maintained in the trace analysis module.

If Modeled State is the state that is actually modeled by an actual analysis tool, then perhaps Traced State is the complete state that it is possible to model using the information stored in a trace. It seems reasonable to have two terms, since we probably don't want to be forced to model everything that could possibly be modeled or suppress all trace events that are irrelevant to the current analysis. Whether the Traced State is stored (conveyed) redundantly or minimally in the trace events would appear to be a minor point from a terminology point of view.

The size of the Modeled state is an issue, since other than the actual state of the system it is maintained and stored over time, sometimes in a memory buffer on the target system. A user making a very long trace may want to store a more compact Modeled State than one looking at a specific point in time. User filters could influence the Modeled State, you could use triggers to automatically filter away parts of the trace etc.

Limited resources could make it difficult to specify a catch-all Modeled State storage format.


> -> our experience with LTTng is that maintaining a modeled state is important for tracing efficiency and for advanced analysis,
>    is it the case for user-space applications as well, can you provide use cases?

All kinds of traces starting with the simplest printf() output is associated with a Traced State. If there's no tool to assist the engineer in building a Modeled State, the engineer will use his own mind, a piece of paper or an excel sheet for this purpose. So yes, advanced (computer-aided) analysis would appear to require a Modeled State, user-space or kernel-space.

Some user-space analyses could be more or less standard, such as modeling the heap using traces of calls to malloc(), calloc(), realloc() and free(). Other user-space analyses are probably custom. Here the extensibility of the format will be put more to the test than in kernel-space tracing.


> 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".

For every trace event we define, there is an underlying idea of a state change in the Traced State. I think it is a wonderful idea to explicitly declare this in the documentation of the standard trace events.


Cheers,

Fredrik