[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Modeled state in TMF/LTTng
|
So then the metadata defines a known type of state machine
by name of a given type, and then trace analyzers can then have a plugin
mechanism to know what to do with that particular state type. Very
simple ones would be built in. For example an integer value occurring
in events that is an enum value that reflects an application/kernel
state is an obvious one. It could then do a presentation of state vs
time. No matter what your kernel/application you can use that one.
Yes, what we used to call the control flow graph could be generalized as
a state timeline: showing the state versus time for a number of entities
(processes, cpu, disks, locks, queues...).
There will then be other ones that are more complex as noted above and
do a bit of non trivial data interpretation. For those, having a plugin
mechanism of some sort by which the raw event data can be
extracted/adjusted into the schema assumed by an analysis plugin would
be great. This could enable usage of the same plugins to do Gantt chart
plotting of scheduler information regardless of whether the OS was Linux
or something else.
Yes, the notion of "synthetic event", generating an event of a more
generic type to represent/replace a "raw" event specific to a platform
can help reusing analysis/viewing modules.
So in summary, I envision that we would have sets of known standard
event schemas, and then a way to transform a given type of data into
that schema via a plugin (as Michel mentions, Python, java, whatever).
There are two possible steps that we are discussing:
- platform specific event (e.g. linux_sched_change p1, p2) replaced by
one or more synthetic event (e.g. task_new_state p1 stopped,
task_new_state p2 running).
- effect of an event (possibly a synthetic event) on the modeled state.
In each case, these actions (creating synthetic events or changing the
modeled state) are a complement to the tracepoint definition (I want to
introduce a new tracepoint and here is the effect of that tracepoint on
the state). They can be either specified declaratively or as plugin
code. What I gather is that from your experience you think that both
will be useful/required, i.e. declarative is preferable but will not be
possible in many cases being too complex?
-OS scheduler Gantt chart
-stock presentation of mutexes and lock/unlock calls (maybe even
suspended process/thread lists)
We can probably get pretty far with a state vs time view applicable to
many different types or resources.
-"analog" value vs. time presentation. (e.g. could be used to present
number of bytes free in a memory pool with some math on the incoming
events)
We probably also want time averages (e.g. I/O per second) and
proportions (process p1 used 64% of the CPU during that interval).
For a particular application that has very specify transformation
necessary on the raw event data, of course you can still have a
specialized plugin/presentation.
One used to say, make 80% of the things easier but make the rest no harder.
