[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [linuxtools-dev] Modeled state in TMF/LTTng
|
Hi,
I did a small analysis based on inventory of 125 trace events in Linux
and MariaDB (instrumented with UST). Here are some observations and
categories of events and how they can be related to states.
* Initial state events: populate the initial state. Some lists are
static (ex: IRQs) and other dynamic (ex: list of open file
descriptors). Those events are found in metadata.
* Events that modify initial state: those events are related to
initial state and modify it. For example, fs.open and fs.close operate
on the file descriptor list.
* Pair of events that define intervals: enter/exit type of events.
Some may be modeled by finite state machine, but the general case is a
pushdown automaton, because some events are nested. In control flow
viewer, we would see the top of the stack. Initial (or final) state is
an issue, because we can't know always for sure the stack state at the
beginning of the trace. Some additional heuristics are needed here.
The sum of time in intervals are interesting to compute and display.
One event can change the state of multiple state machines, for example
sched_schedule that update the CPU and two processes.
* Counters: some events purpose is to be accumulated and plotted on
histogram. For example, in MariaDB there is cache_hit and cache_miss
events. Absolute values are not interesting here, we need a ratio of
those two events. Some data inside the payload can be accumulated, for
example reads and writes on a file. Occurences of all events may be
interesting, this special case doesn't need to be declared at all.
Here are the number of events of each type. One event can belong to
more category.
-----------------------------------
event type | occurences
-----------------------------------
interval | 73
modify initial state | 13
metadata | 21
counter | 9
not classified | 16
-----------------------------------
In the set of unclassified events, there are events that would change
the data structure in such a complex way that it would be hard to
generalize their behavior. For example, events that changes the bloc
queue list. Some other doesn't do much at all, like printk.
Anyway, I hope this small analysis continue to drive ideas forward.
Have a nice day,
Francis