[lttng-dev] [CTF] Dynamic enumerations and state system

[Mathieu Desnoyers]

* Alexandre Montplaisir (alexandre.montplaisir at polymtl.ca) wrote:
> Hi Aaron,
> 
> On 12-01-17 06:21 PM, Aaron Spear wrote:
> > Hi Mathieu and Alexandre,
> >
> > ----- Original Message -----
> >> From: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> > ...
> >> Good to hear that the state tree is a good container for this kind of
> >> information. So I'll drop the "dynamic enumerations" from my CTF
> >> roadmap.
> >
> > It does seem though that in any case CTF meta-data must have a standardized way to express that a value is a "state" though right?  (as well as some help for interpretation of the state value).  Take a counting semaphore for instance.  Every OS I have seen has some sort of control block that has an integer that is the count.  Every post or wait increments or decrements the count respectively.  It would be nice if we could describe this for any OS with just annotations on the wait and post events in the CTF meta-data.  Then the analyzer would be able to display the semaphore value at any point in time without knowing anything special about the OS.
> 
> Mathieu correct me if I'm wrong, but I think the "event context" in CTF
> can do just that. It could for example include the new value of the
> counting semaphore as part of the event.

Nope, that's not quite right. If you have, say, 300 mutexes in your
system, you cannot hope to add event context information to write the
mutex state of each of the 300 mutexes at each and every event traced.
This is where you need to track the mutex calls to keep track of the
mutex state changes with a state system.

What Aaron refers to here, I think, is that we should enhance CTF to
support description of the impact events have on state, as proposed in
http://git.efficios.com/?p=ctf.git;a=blob_plain;f=common-trace-format-reqs.txt;hb=master
section: Optional per-event "current state tracking" information.

There are some cases where the state information can be expressed in two
different ways, e.g.: currently running vpid. This can be extracted from
sched_switch events in the Linux kernel, and we can track the current
vpid with a state system. It can also be tracked by adding an event
context field "vpid", which writes the current vpid for every event.

The choice between the two is a question of space/bandwidth and
frequency of state change. For instance, it would make no sense to trace
the "perf counter" events and get their change with a state system,
because they happen to change all the time. This is where sampling them
with the event makes more sense.

Thanks,

Mathieu

> 
> Some trace formats, like SLOG-2, offer support for both events (1
> timestamp + values) and states that have a duration (so 2 timestamp + a
> "state value") directly in the trace. AFAIUI, CTF only supports events,
> but to which you can add context information.
> 
> 
> For LTTng however, we have separated the notion of "state system" from
> the trace file itself. We are currently working on implementing this as
> a library that can then be used by trace viewers like LTTV. This library
> will have input plugins for each trace type, in which we would define
> the state information we want to build from a trace.
> For example, in a CTF kernel trace we could assign state changes to the
> "wait" and "post" events, which would increment and decrement a value in
> the model. That way the viewer could retrieve the value of the semaphore
> at any point in time, even if there is no context information in the
> trace itself.
> 
> >
> > cheers,
> > Aaron Spear
> >
> 
> Cheers,
> 
> -- 
> Alexandre Montplaisir
> DORSAL lab,
> École Polytechnique de Montréal
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com