[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Upcoming UI features
|
On 2016-02-16 10:57 AM, Matthew Khouzam wrote:
Hi All,
We're developing some new views and revamping old ones in tracecompass,
I think we are at the point where we can seek feedback.
1- Split the resources view into an Execution context view and an
Interrupts view.
Hi Matthew,
Modeling the IRQ information per CPU is important, as pointed out in bug
381497 [1]. However, it is also important to keep the "aggregate"
information, because there are use cases that make heavy use of this
(following the activity of one IRQ or one driver through the trace for
example). There is a problem right now with our current model, because
we don't split it per CPU. The new version should show something like this:
IRQ 1 ---[----][----][-----]
CPU 0 ---[----------]-------
CPU 1 ---------[-----------]
where if there is an "overlap" of the same handler being run on
different CPUs the same time, it should be represented correctly in the
aggregate row. This means there should still be an attribute for "IRQ 1"
in the state system to hold this information. This is at the core of
fixing bug 381497, and the patches posted so far do not address this.
I think this would make a good first step. Afterwards, we could decide
if we want to split the CPU sub-trees and IRQ sub-trees in different
views. I would tend to think that would make sense (to split them),
because I can't think of any use case where you would want to look at
both at the same time. They would both show basically the same
information, only indexed differently, so you'd be using one view or the
other.
2- Show CPU usage for a given CPU
3- Follow thread
This is another interesting topic. I have mentioned previously the idea
of extending the TmfTraceContext to be able to hold additional
information provided by analyses. Things like a "current selected
thread" and a "current selected CPU" would be a perfect example. I see a
patch [2] was posted to add signals indicating thread or CPU selection.
This is pretty good, but it would also require a similar addition to the
trace context, just like we do with time stamp and visible range
selections. That way if a view is closed when a signal is sent, but
opened later, it can still query what is the current thread/CPU it
should show.
Another thing to keep in mind: would it be possible to select multiple
threads or CPU at once? That could be very useful too.
There are plenty of use cases where this approach would fit:
The CPU usage view could update to show the CPU usage of selected
thread(s) or CPU(s), like in your example.
The Critical path analysis could be turned into a "on-demand analysis"
(like the other external analyses I was talking about in my other email
about lttng-analyses integration), which would retrieve which thread is
currently selected from the trace context. Perhaps even the current time
range too. That would help in removing the heavy coupling between that
analysis and the Control Flow view.
Cheers,
Alex
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=381497
[2] https://git.eclipse.org/r/#/c/65594/
