[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Modeled state in TMF/LTTng
|
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.
By having the "state machine" in the trace points themselves, the
viewers won't need to be updated independently. Want to add a new trace
point? You can (optionally) also add its relevant state modifications at
the same time, and the viewers will interpret it correctly.
This is particularly interesting for userspace applications,
instrumented with UST for example. We could provide a generic way to
define attributes and state changes in the tracepoints, and anyone
instrumenting their application could tailor it to their needs.
For example, in a database application, they could specify that this
event in sets the "connection" attribute to "active", and that other
event (in the hypothetic close_connection() function) sets the attribute
to "inactive". Then when you'd open the resulting trace in a viewer, you
could see in a different color the period when the connection was active.
There's better examples in Mathieu's trace format proposition, of which
I copied an excerpt below.
On 2010-12-09 11:01, Mathieu Desnoyers wrote:
> - Optional per-event "current state tracking" information.
>
> This per-event taxonomy allows automated creation of a state
machine that
> keeps track of state updates within the taxonomy tree.
>
> Described in an file-system path-like taxonomy with additional []
> operator which indicates a lookup by value, e.g.:
>
> * For events in the trace stream updating the current state only
based on
> information known from the context (either derived from the
per-section or
> per-event context information):
>
> E.g., associated with a scheduling change event:
>
> "cpu[section/cpu]/thread = field/next_pid"
> Updates the current value of the current section's cpu
"thread" attribute
> (e.g. currently running thread).
>
> E.g., associated with a system call:
>
> "thread[cpu[section/cpu]/thread]/syscall[field/syscall_id]/id
> = field/syscall_id"
>
> Updates the state value of the current thread "syscall" attribute.
>
> * For events in the trace stream targeting a path that depends on
other
> fields into that same event (would be common for full system
state dump at
> trace start):
>
> E.g., associated with a thread listing event:
> "thread[field/pid]/pid = field/pid"
>
> E.g., associated with a thread memory maps listing event:
> "thread[field/pid]/mmap[field/address]/address = field/address"
> "thread[field/pid]/mmap[field/address]/end = field/end"
> "thread[field/pid]/mmap[field/address]/flags = field/flags"
> "thread[field/pid]/mmap[field/address]/pgoff = field/pgoff"
> "thread[field/pid]/mmap[field/address]/inode = field/inode"
>
> All per-event context information (e.g. repeating the current PID
and CPU
> for each event) can be represented with this taxonomy, e.g., in the
> section description:
>
> "section/pid = field/pid"
> "section/cpu = field/cpu"
--
Alexandre Montplaisir
DORSAL lab,
École Polytechnique de Montréal
