Re: [linuxtools-dev] TMF: Expressing dependency information and displayi

[Bernd Hufmann <bhufmann@xxxxxxxxx>]

Hi Geneviève

Please see below.

BR,
Bernd

On Mon, Mar 25, 2013 at 11:58 AM, Geneviève Bastien
<gbastien@xxxxxxxxxxxx> wrote:
> Hi all,
>
> As trace analysis tools become available in TMF (trace synchronization,
> critical path calculation, latency, etc), a requirement is to be able to
> express dependencies between events.
>
> After discussions and seeing the work done so far on trace analysis, here is
> a proposal for how to express and display those dependencies.
>
> **Modeling the dependencies**
>
> I'd propose to use a graph structure to represent those dependencies (a set
> of vertices - an object at a given timestamp - and edges - a link between
> two vertices).
>
> * The edges would be directed, but the graph would not necessarily be
> connected.
>
> The graph would be
> * sortable (by timestamp of vertices)
> * subsettable (for a given timerange, for given processes/entries)
>
> Each type of trace analysis would produce its own graph of dependencies, as
> the edges needed by each are not the same.  Each graph will be saved to disk
> as a supplementary file.
>
> **Displaying the dependencies**
>
> As for displaying those dependencies, it could be done through layers on the
> Control flow view.  Just like in Google Map, one could select the layers to
> display and the corresponding graphs will be drawn over the control flow
> view.
>
> In order to do this, we'll first need to modify the TimeGraphCombo (or copy
> and add a new view?), the tmf widget with entries on the left and a drawing
> canvas on the right, to support different layers.
>
> We'll have to take care not to clog the view and maybe need to sort the
> entries a bit so as to limit the number of super long arrows going from an
> entry at the top to an entry at the bottom.  At least it should be possible
> to filter the entries shown so that only those that have dependencies are
> shown.
>
> The dependency graph could be displayed also as a sequence diagram. It could
> also be exported as a dot file and visualized in external tool like
> graphviz.
>
TMF comes with Sequence Diagram Framework which can be easily
extended. So I would encourage to use this Framework to draw sequence
diagrams.
For more information about the TMF Sequence Diagram Framework see
http://wiki.eclipse.org/Linux_Tools_Project/TMF/User_Guide#TMF_UML2_Sequence_Diagram_Framework.

When we introduced the the sequence diagram framework we planned to
have a declarative way (e.g in a XML) to define how to translate
events to interactions and lifelines. This hasn't been done.
Currently, an example java implementation
(org.eclipse.linuxtools.tmf.ui.views.uml2sd.loader.TmfUml2SDSyncLoader.java)
exists as reference or base for further implementations. However,
maybe with the addition of a data driven state system through an XML
file it is a good time to also define a data driven sequence diagram.

> **Implementation**
>
> For now, this dependency implementation would be hardcoded for dependencies
> on lttng kernel traces, but in the long run, the syntax proposed in previous
> threads by Florian Wininger and Aaron Spear will be extended to be able to
> support expressing the dependencies from trace events.
>
> For example, we should be able to express something like this (these are
> just examples, exact syntax or schema will depend on what is implemented in
> TMF):
>
> my_send_event(to=(.*),packet_no=(.*)).match(my_receive_event(to=\1,sequence=\2))
> to create an edge from the my_send_event to my_receive_event.
>
> or
>
> event: sched_switch:dependency from task(event.prev_tid) to
> task(event.next_tid)
> to create an edge from the previous task to the next task of a sched switch.
>
>
>
> This is the big idea.  I would like to get some feedback on this proposal.
> Does that make sense?  Any complications ahead?  Better ideas?
>
> Thanks,
> Geneviève
>
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev