| Re: [tracecompass-dev] [RFC] A model for a host instead of multiple analyzes |
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. Cheers, Alex 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 > https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
Attachment:
signature.asc
Description: OpenPGP digital signature