[tracecompass-dev] [RFC] A model for a host instead of multiple analyzes

[Geneviève Bastien <gbastien+lttng@xxxxxxxxxxxx>]

Hi all,

So I've been thinking... and prototyping and talking... And here's a
thought.

Right now, we have multiple analyzes that each populate one state
system. Each analysis belongs to a single trace, or experiment, and
whenever we need some information from that analysis, we need to know
its name, ID, the trace it belongs to, etc. That means that, for a UST
trace for example, if we want to know which thread was on the CPU at the
time t (and the context.vtid was not enabled), we need to do some
gymnastic with Event aspects, if we have an event, or some
TidProviderForHost that would look for a trace for the same host that
has this information. The code for that is not clean (I have it somewhere)

But what we're really doing with kernel/[potentially multiple] ust
traces is to analyze a given system. So why not have a SystemModel
class, representing a host, that would abstract all of this logic away,
then you just query the model for the tid at time t on CPU x, or the
file name with FD f, no need to look for other traces for a host that
might have the information we need. That would be much cleaner I think.

We could implement this gradually:

1- Just add a SystemModel class for host, that would get the analyses
that contain a given information (mostly the kernel trace analyses). The
analyses will continue working as usual.

2- Deprecate all the utility methods currently linked with analyses,
like the KernelThreadInformationProvider class and use the SystemModel's
equivalent method instead.

3- Then, the SystemModel class could start managing how the data is
stored (state system, segment stores depending on the data), the
analyses will just populate the model, that will save the information
the way it wants.

This has the advantage that multiple analyses can populate the same
informations, unlike now. For a concrete example, let's consider all the
thread called java in the Control Flow View when we trace TraceCompass.
With a JUL trace, we could add the information to the model of which
thread was actually doing what, so that the Control Flow View will
display the actual name of the thread.

Another advantage is that a big analysis like the Kernel Analysis Module
can populate multiple smaller state systems, it's the model that will do
it. For example, say we have  model.sched_switch method that changes the
thread on CPU, the model can put it in various places depending on the
query pattern, so the TID analysis and CPU usage analyses won't be
necessary anymore, the model will take care of it.

Any ideas, thoughts, comments?

Cheers,
Geneviève