Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linuxtools-dev] Tmf: a model to support new trace analysis types 
Hi Alex,

Thanks for your feedback.
Just to be clear: experiment types and this analysis types model are two different things. * Experiment types[1] are an extension of the experiment to allow the user to define 'roles' for the traces composing it. Traces can then be treated differently according to their role in the analyses. * By analysis, I mean action requiring trace processing and having some kind of output. They may apply to traces (ex. computation of execution graph), experiments (ex. trace synchronization) or experiment types (ex. Virtual machine-host analyses like described by Mohamad last week).
[1] Experiment types were discussed off-list with some members of the TMF team at Ericsson. Those two patches start the implementation of this. 
https://git.eclipse.org/r/#/c/13787/
https://git.eclipse.org/r/#/c/13789/
The experiment type concept can continue to live its development/review life cycle as if this discussion was not occurring ;-) 

Comments below.

On 07/15/2013 02:35 PM, Alexandre Montplaisir wrote:

Interesting stuff! As we discussed previously however, "everything is an
analysis" is quite far from what we have currently in the framework.
Perhaps it'd be easier to go step by step, starting with introducing
experiment types.

I won't be touching what is currently in TMF, only add new stuff.

Right now the trace type defines some of the elements you put in the
"analysis" (like state systems and custom statistics). It's also
possible to define a specific perspective (collection of views) in the
plugin for a trace type. (The framework could be improved wrt that, for
example automatically opening the perspective that matches the type of
the trace that is opened.)
It's more than changing perspective. With the proposed approach, analysis modules may come from varied sources and not necessarily be part of TMF and linuxtools, so they won't be able to modify the perspective and won't need to touch TMF. Anyway, many analyses can be done on a single trace and modifying the perspective for each one would be a pain and changing the trace type to have access to another analysis is not the best idea. Why force the user to choose between the butter or money for the butter, when you can have it all! 
Even if you have two identical trace types,
but you want two different kind of analysis on them, this can be done
today by having two different trace types in the list. The user has to
make this decision at one point or another.

I just want to make sure that we have (ideally many) alternative use
cases and working examples before we start making big modifications to
the framework. If we dive in and start coding a big framework, most of
it might need to be rewritten when we get to integrating actual analyzes.
We have here the trace synchronization and execution graph/critical path to test this approach with. Hopefully, Mohamad's analyses can make use of it as well. 

Some comments below,


On 13-07-12 03:43 PM, Geneviève Bastien wrote:

Hello,

As more and more trace analysis are getting available for TMF, I think
we should have an easier, more modular way to add new analysis.

 From my experience with trace synchronization and execution
graph/critical path, an analysis typically has to be implemented (a
few more packages in tmf.core), it provides a view or more (in tmf.ui
or the trace's .ui plugin), sometimes needs a handler for the project
view (new classes in tmf.ui) and the trace needs to know about it
(modification of the trace classes, even the ITmfTrace). tmf.core and
tmf.ui are getting very crowded.

Here's the analysis framework I'd propose to add new analysis:

In tmf.core:
   * A new analysis manager that handles the content from the extension
point described below
   * Base classes and interfaces for all analysis

Implementation detail, but do you intend on extending TmfExperiment for
this? Maybe the current TmfExperiment could be renamed to a more generic
"TmfTraceSet", and and Experiment would become a traceset with a
specific type given (like VM+host anlysis, etc.)
As mentioned there are two different concepts. New base classes will need to be implemented. 
   * ITmfTrace will have new methods to get all applicable analysis for
a given trace type and execute them when necessary

New extension point "org.eclipse.linuxtools.tmf.core.analysis"
An analysis has
   * class: Class that implements this analysis
   * tracetype: class of the trace it applies to (default: all traces)
   * requires: other analysis modules that are required to run before
this one

Not sure this is required in the extension point. The trace type or the
analysis code itself can .waitUntilBuilt() / .waitForCompletion() on any
event requests, state systems, or other analyzes it needs.

Indeed after discussing with Francis, this is not there anymore!

   * automatic: whether to run this analysis when the trace is opened
(default: false)
   * provided views: which views will be available once the analysis is
done

This can be done with a perspective shipped in the analysis plugin. The
trace type or analysis type can then refer to it.
Maybe some analyses module can provide their own perspective, but usually, only one extra view would be provided and could be more easily just opened by clicking on it in the project explorer (yeah, somewhat like the Windows approach :p ) 


   * icon: to represent this analysis
The project explorer view could show the analysis like this for example:
- My Project
   - Experiments [1]
     - SyncExperiment
       - Trace 1
       - Trace 2
       o Analysis: trace synchronization
         o Synchronization view
         o Synchronization statistics view
   - Traces [2]
     - Trace 1
       o Analysis: Lttng Kernel state system
         o Control flow view
         o Resources view
       o Critical path
         o Critical path view
....

The "mandatory" analyzes can be done today with how we handle trace
types (buildStatistics(), buildStateSystems(), etc.). The optional ones
however would be a new concept. Maybe we could have something like a
right-click menu option, "Apply analysis" -> "Critical Path analysis",
so the code is only ran when asked to do so. Or it could be done
automatically when the view is opened.
I was thinking on a "on demand" approach for optional analyses, when the view is opened (so when the output of the analysis is required). Of course, that would mean to wait on the analysis when we want the view now... 


In the long run, the actual state system and statistics could be
considered analysis types and be refactored using this framework.

Not a big fan of this ;)  So far we've been able to keep everything
included in the trace type extension point. We should be able to do the
same with the experiment type extension point, short-term at least. It
prevents extension point bloat, and makes it easy to extend/modify
existing types by using OOP inheritance and polymorphism.


Each new analysis can then be implemented in its own standalone
plugin, with core and ui, which would require only the tmf.core|ui
(and the plugins containing other analysis it requires of course). The
main plugins would not require any analysis modules.

I'd like some feedback on the proposed approach.  I know Francis
Giraldeau has been thinking on this problem as well, mostly on the
dependencies between analysis.  I think this approach is complementary.

Hope the feedback was useful. ;)  Let the discussions begin!
Thanks for the feedback. I hope this clarifies the difference between experiment types and analysis modules (and convinces that both are useful and required ;-) 

Thanks,
Geneviève


Cheers,
Alexandre


Thanks,
Geneviève Bastien

Back to the top