[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] Upcoming UI features
|
Hi Matthew
Thanks for looking into this. See below for some comments from my side.
Bernd
On 02/16/2016 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.
Here's the premise, right now, we have a resource view that is flat out
lying to the user, and also betraying the mental model of an OS kernel.
Why such a statement, the IRQ and SoftIRQ lines are shared across your N
cores. Also, it makes people think that these handlers are some magical
things that don't run on a CPU. IRQs and Soft IRQs are just code. They
may be triggered differently but always run on a cpu.
To fix this, I propose splitting up the views into two:
A- the CPU view can be called an execution context, it shows what
each cpu core is doing at any given point in time. It can remain the
"resources" view, and we can add GPU/HDD/Network info into it at a later
date, but for now, it has the cpus as before, but as sub-tree elements,
the interrupts are shown. This is very useful when you have located
where a problem is and what to know what it is. Here is a screenshot
*http://i.imgur.com/WhefG0H.png*
B- the interrupt view. This aggregates Soft IRQs and IRQs by vector
number. I don't see it personnaly as very useful on a microscopic level,
but it may have value on a larger scale. Possible improvements later
could be to show it by handler instead of vector, so you can track an
actual driver and not an IRQ number. It can be a valid way of finding
where a problem is. Here is a screenshot http://i.imgur.com/813DCpN.png
It would be possible to put the content of the interrupt view in the
resources view instead. However, logically it makes probably sense to
have separate views.
So I would suggest is to introduce the interrupts view first and keep
the Resources view as is. Then updated the Resource view to remove the
IRQ/SOFTIRQ lines and add them to the CPUs as children lines.
Unless we receive clear feedback that we should not have 2 views and
keep the changes in the Resources view instead, we can go ahead with
this plan.
2- Show CPU usage for a given CPU
If you ever manually set your affinities on your threads, this
enhancement will help. It basically will allow you to select a cpu by
right clicking on the resources view CPU entry and a context menu saying
: "Follow CPU <cpu number>" will appear, selecting it will make the cpu
usage view filter out all other cpu information.
This is an interesting approach to use the Resources view for such a
purpose. One thing we have to make sure that it's clear from which trace
the cpu selection is coming. I mean if the current active trace is an
experiment with multiple traces with notion of CPUs it has to be clear
which trace it comes from.
This is the first step, if it flies, we will add filters on all views
that have a cpu notion (resources, interrupt, events table)
A screenshot is available here. http://i.imgur.com/diVl8QN.png
Upon reception of a follow CPU, the relevant views can apply appropriate
filter.
As a separate feature we could have local, per view filtering based on
CPUs. We have that already in the Resources view. We could add that to
other views (e.g. CPU Usage view)
3- Follow thread
How often are you tracing to figure out what's going on in your system
and there's no slowdown? How do you know there's a slowdown? You
probably observed a program being slow. This is an option added to the
control flow view to right click on a thread and then a thread wait
density and statistics view can access the information. With these
views, outliers can be easily spotted.
This view should be very useful to locate problems, not to figure them
out, but in a 10 minute trace, this can bring you to the interesting
milliseconds.
Here are two screenshots http://i.imgur.com/jA6ZS16.png
http://i.imgur.com/hGoOZfj.png
Similar comments than for the CPU filtering.
An example of the build with these features can be found here by 12:00
pm today
https://hudson.eclipse.org/tracecompass/view/Obsolete/job/tracecompass-master-rcp-test/lastSuccessfulBuild/artifact/
Finally, here is the album with all the screenshots http://imgur.com/a/45qTl
TL;DR
For all those with limited patience, download this
https://hudson.eclipse.org/tracecompass/view/Obsolete/job/tracecompass-master-rcp-test/lastSuccessfulBuild/artifact/
look at these pics http://imgur.com/a/45qTl
Please tell us if you object to any of the views,
BR Matthew
_______________________________________________
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
