Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] [RFC] A model for a host instead of multiple analyzes

Just a +1 for the idea of a trace collection.  I am using a trace experiment to give the user the feeling that a set of text-based trace files are one logical trace.  This works pretty well, but having a first class trace collection could be cleaner for this use case.


On Mon, Oct 17, 2016 at 12:45 PM, Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx> wrote:
Hi Geneviève,

This made me think of something. I'll go on a tangent for a bit, but
then it leads back into your problem, please bear with me ;)

How about introducing the long-sought concept of "trace collection",
which would be like an experiment, but that is always there. Quick
recap, the user adds traces to a "trace collection", then open, closes
trace collections, not individual traces. This would effectively work
like an experiment, except that

* It would NOT share the same class hierarchy
* It would always be present in the model, so a single trace would still
be part of its own trace collection.

The first point helps make it clearer where some elements should be
stored, at the trace-level, or at the trace-collection-level. Analyses
would continue to be part of individual traces, but other concepts, like
the SystemModel you are talking about, would fit better at the
collection level. It could, for example, look into all the traces
present in the collection to populate a model of what thread is on what
CPU on what host at a given timestamp.

I think a top-down approach like this would work better than a bottom-up
one, where sub-analyses would have to know about a SystemModel in a
layer above them and populate it.

There's probably many other details to ponder about, but that's one
potential approach.


On 2016-10-17 08:23 AM, Geneviève Bastien wrote:
> 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
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit

tracecompass-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top