[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tracecompass-dev] Event requests precedence
|
Hi Genevieve
Right now the coalescing is done per event provider (ITmfEventProvider)
which is either the trace (TmfTrace) or the experiment (TmfExperiment).
Coalescing of requests across event providers is not supported right
now. Actually, it was supported a long time ago where each request was
sent by the experiment as event provider regardless of the request came
from the trace or the experiment. This was changed to allow analyses to
be scheduled independently. This type of coalescing lead to that a trace
file was only read once (during indexing and building of analyses
results) and each event was simply dispatched to the interested traces
and experiment.
A few month ago, we discussed to implement coalescing of request across
event providers to bring back the original behaviour but still
supporting the new use cases of analyses. At that time, we were hoping
to get some performance improvement when analysing experiments by
avoiding concurrent reading of the traces files. I implemented a series
of patch sets for that support. Even if functionally, the changes were
working and the coalescing goal was achieved, it didn't show much
performance improvement (nor degradation) and we decided to not merge it
at the time.
So what this series of patches does, is to introduce a parent-child
relation between event providers. An experiment event provider, is the
parent of a trace event provider. Experiments could have other
experiments as children. When sending a request using a trace event
provider, the trace event provider was aware of its parent and would
dispatch the request to the parent. If the parent was able to coalesce
the request it did so, otherwise it would be sent by the trace.
For your use case, this series of patches would help. It would make sure
that each event is processed in a coalesced request from the experiment
and its traces. However, the order of how events are processed is not
guaranteed and there is no means right now to order them. This would
have to be implemented on top of the patches. Having priorities, like
Alex suggested, could be one way to go.
Here is the reference of the series of patches:
1) https://git.eclipse.org/r/#/c/23631/
2) https://git.eclipse.org/r/#/c/23632/
3) https://git.eclipse.org/r/#/c/23633/
4) https://git.eclipse.org/r/#/c/23634/
Please have look and see if this will be useful with your use case.
Best Regards
Bernd
On 10/31/2014 03:06 PM, Geneviève Bastien wrote:
Hello,
I would like some information on how the event request coalescing
works as of now and how I could make the following use case work:
* I have an analysis for an experiment (let's call it the virtual
machine analysis) that runs an event request on the experiment.
* That analysis also depends on individual analysis from the traces of
the experiment (concretely the LttngKernelAnalysisModule from each
kernel trace).
* When the experiment analysis module is executed, it also makes sure
the LttngKernelAnalysisModule from each child trace is executed.
* But when I handle an event in the experiment, I want to be sure that
tihe LttngKernelAnalysisModules have run with this event before
handling it in the experiment.
If I just let things run by themselves right now, the order of the
requests is random so the event may or may not have been handled by
the traces before it is by the experiment.
How would be the best way to solve this?
Thanks,
Geneviève
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev