Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Trace Compass/Project Meetings/2016-04-15"
(Merge edit by Gbastien+lttng.versatic.net) |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | == Attendees == |
| − | + | * Alexandre Montplaisir (EfficiOS) | |
| + | * Jonathan Rajotte (EfficiOS) | ||
| + | * Matthew Khouzam (Ericsson) | ||
| + | * Patrick Tassé (Ericsson) | ||
| + | * Marc-André Laperle (Ericsson) | ||
| + | * Jean-Christian Kouamé (Ericsson) | ||
| + | * Bernd Hufmann (Ericsson) | ||
| + | * Geneviève Bastien (Polytechnique) | ||
| + | * Loïc Prieur-Drevon (Polytechnique) | ||
| − | == | + | == Minutes == |
| − | === | + | === Go over AIs of last meeting === |
| − | + | No Action Items last week. | |
| − | + | === SS Serialization === | |
| − | + | ||
| − | * | + | Alex did a recap of the state system serialization saga. |
| − | * | + | * Patches were proposed to make state values themselves serializable. |
| + | * A future step would have been to move the state system to write all state values as [size]+[byte array]. | ||
| + | * After all it was decided against, because it would make the state history bigger and slow down (due to in-memory copies) the common cases. | ||
| + | * The basic-type-specific logic in HTInterval is to remain, which means there is no point in having a serialization method in the interface any more. | ||
| + | |||
| + | However, state-value-defined serialization will still be useful for the upcoming Custom state values Geneviève is working on. | ||
| + | * Serialization methods can be present only in the Custom SV interface. | ||
| + | * We'll have to implement a "safe" byte buffer, extension or wrapper, to use in the API. | ||
| + | * Geneviève / Matthew will work on it and Alex will review. | ||
=== Data from parallel analyses === | === Data from parallel analyses === | ||
| − | + | An analysis can ask for data coming from another analysis. In some cases, it can block the coalesced request's queue, which also blocks the other analysis, resulting in a deadlock. | |
| − | + | See https://bugs.eclipse.org/bugs/show_bug.cgi?id=488757 . | |
| + | |||
| + | There are two problems: | ||
| + | |||
| + | ==== Analysis has to know its available times ==== | ||
| + | |||
| + | Introduction of a new method: | ||
| + | boolean isQueriable(timestamp) | ||
| + | |||
| + | ==== Avoiding the deadlock ==== | ||
| + | |||
| + | Three solutions were mentioned: | ||
| + | * Move the events queue from AbstractStateProvider up to the analysis, so that all analyses have their own event queue. | ||
| + | * Put the queue in the coalesced event request directly. If a queue is full it can "uncoalesce" the request that is blocked. | ||
| + | * Don't even coalesce requests you know that may block. Whoever creates the request has to know what type of request to send. | ||
| + | |||
| + | Given the short time, Bernd's suggestion (the third one) is interesting, as it does not require change to the existing request code. We will aim to do that for Neon. Small API changes may be needed in TmfEventProvider. | ||
| + | |||
| + | === State system APIs === | ||
| + | |||
| + | Loïc mentioned some changes he would like to make to the state system API: | ||
| + | |||
| + | * rangeQuery directly in ITmfStateSystem | ||
| + | ** Can benefit from its own implementation, instead of just doing a wrapper around single queries. | ||
| + | * Multiple-attribute query at a single time | ||
| + | ** Again, this can benefit from a custom implementation, instead of doing a full query and just picking the values we want. | ||
| + | * Core attributes are not being used : results in one long interval | ||
| + | ** This is more a problem of state providers in general. By making use of "empty" attributes we can save space and intervals. | ||
| + | |||
| + | Discussion will continue on the mailing list. Alex and Loïc will schedule a separate meeting to talk about the details. | ||
| + | |||
| + | === Critical Path for Neon === | ||
| + | |||
| + | These items are considered to be on the "critical path" for the Neon feature freeze, and each party would like to get them in: | ||
| + | |||
| + | ==== Ericsson ==== | ||
| + | |||
| + | * Integration of XML data-driven analyses | ||
| + | * Some views are not populated when they are part of an experiment | ||
| + | ** Maybe have a way to manually populate a view from a single trace that is part of an experiment | ||
| + | * Update LTTng Control to 2.8 with current existing features | ||
| + | ** Includes some MI changes | ||
| + | |||
| + | ==== Poly ==== | ||
| + | |||
| + | * XML API to be made all internal | ||
| + | * API for parallelize analysis bug (isQueriable) | ||
| + | * Custom state values | ||
| + | |||
| + | ==== EfficiOS ==== | ||
| + | |||
| + | * LTTng 2.8 Debug Info analysis | ||
| + | * LTTng-Analyses integration (no API changes) | ||
| + | |||
| + | === Demos === | ||
| + | |||
| + | * Alex demoed the 2 EfficiOS features mentioned above. | ||
| + | * Didn't have time for the other new features, but Matthew did a high-level explanation. | ||
| − | == | + | == Action Items == |
| − | * | + | * Matthew/Geneviève to update patch on SS serializaton. Alex to review. |
| + | * Alex to look at Loic's patch | ||
| + | * Loïc to send an item on the ML | ||
| + | * Alex to make sure LTTng 2.8 source lookup fallbacks to old workspace lookup action | ||
| + | * Alex and Loïc to coordinate to continue discussion on the state system changes (early next week) | ||
| − | + | [[Category:Trace_Compass]] | |
Latest revision as of 14:46, 13 February 2024
Contents
Attendees
- Alexandre Montplaisir (EfficiOS)
- Jonathan Rajotte (EfficiOS)
- Matthew Khouzam (Ericsson)
- Patrick Tassé (Ericsson)
- Marc-André Laperle (Ericsson)
- Jean-Christian Kouamé (Ericsson)
- Bernd Hufmann (Ericsson)
- Geneviève Bastien (Polytechnique)
- Loïc Prieur-Drevon (Polytechnique)
Minutes
Go over AIs of last meeting
No Action Items last week.
SS Serialization
Alex did a recap of the state system serialization saga.
- Patches were proposed to make state values themselves serializable.
- A future step would have been to move the state system to write all state values as [size]+[byte array].
- After all it was decided against, because it would make the state history bigger and slow down (due to in-memory copies) the common cases.
- The basic-type-specific logic in HTInterval is to remain, which means there is no point in having a serialization method in the interface any more.
However, state-value-defined serialization will still be useful for the upcoming Custom state values Geneviève is working on.
- Serialization methods can be present only in the Custom SV interface.
- We'll have to implement a "safe" byte buffer, extension or wrapper, to use in the API.
- Geneviève / Matthew will work on it and Alex will review.
Data from parallel analyses
An analysis can ask for data coming from another analysis. In some cases, it can block the coalesced request's queue, which also blocks the other analysis, resulting in a deadlock. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=488757 .
There are two problems:
Analysis has to know its available times
Introduction of a new method:
boolean isQueriable(timestamp)
Avoiding the deadlock
Three solutions were mentioned:
- Move the events queue from AbstractStateProvider up to the analysis, so that all analyses have their own event queue.
- Put the queue in the coalesced event request directly. If a queue is full it can "uncoalesce" the request that is blocked.
- Don't even coalesce requests you know that may block. Whoever creates the request has to know what type of request to send.
Given the short time, Bernd's suggestion (the third one) is interesting, as it does not require change to the existing request code. We will aim to do that for Neon. Small API changes may be needed in TmfEventProvider.
State system APIs
Loïc mentioned some changes he would like to make to the state system API:
- rangeQuery directly in ITmfStateSystem
- Can benefit from its own implementation, instead of just doing a wrapper around single queries.
- Multiple-attribute query at a single time
- Again, this can benefit from a custom implementation, instead of doing a full query and just picking the values we want.
- Core attributes are not being used : results in one long interval
- This is more a problem of state providers in general. By making use of "empty" attributes we can save space and intervals.
Discussion will continue on the mailing list. Alex and Loïc will schedule a separate meeting to talk about the details.
Critical Path for Neon
These items are considered to be on the "critical path" for the Neon feature freeze, and each party would like to get them in:
Ericsson
- Integration of XML data-driven analyses
- Some views are not populated when they are part of an experiment
- Maybe have a way to manually populate a view from a single trace that is part of an experiment
- Update LTTng Control to 2.8 with current existing features
- Includes some MI changes
Poly
- XML API to be made all internal
- API for parallelize analysis bug (isQueriable)
- Custom state values
EfficiOS
- LTTng 2.8 Debug Info analysis
- LTTng-Analyses integration (no API changes)
Demos
- Alex demoed the 2 EfficiOS features mentioned above.
- Didn't have time for the other new features, but Matthew did a high-level explanation.
Action Items
- Matthew/Geneviève to update patch on SS serializaton. Alex to review.
- Alex to look at Loic's patch
- Loïc to send an item on the ML
- Alex to make sure LTTng 2.8 source lookup fallbacks to old workspace lookup action
- Alex and Loïc to coordinate to continue discussion on the state system changes (early next week)