Community
Participate
Working Groups
Currently, trace-compass will show a row for "CPU X Threads" and "CPU X States" in the Resources view. However, for Android systems - looking at CPU frequency is quite important, as a function of time, and is often correlated with tasks that are causing the frequency spike. It will great to have an addition row for that "CPU X Frequency" if its available in the trace. This is one of the main selling points of the widely used Android systrace viewer (which I agree is not as awesome as tracecompass in other respects, but in this respect it is)
Any thoughts or updates about this? Someone within Android organization also just asked me for this, they are looking forward to using tracecompass for trace viewing of android features, but this is quite an important one. thanks a lot!
I'll take a look at that, it shouldn't be too hard to implement, I had one XML analysis for the frequency a long time ago. But we do have to see if it impacts performances (it would increase the backend size, but it scales better than it used to), and if we want the CPU frequency shown by default or if it just clutters the UI. How is it shown in systrace? Just another line for that CPU? or do you have any other way of visualizing this? Any thoughts/screenshots of how you would like to see this?
I personally like this idea a lot. Question, would power mode be more appropriate? Also, would the row be better in the cpu status, I think it should be * CPU Status ** CPU Frequency ** Kernel ** SoftIrqs ** IRQs ** IPIs ** NMIs ** Faults Not that we want this in THIS bug, but I want to know, should it be in CPU status? I think so. (end of ramble)
Created attachment 273762 [details] Hi, Thanks for the reply. Attached is a screenshot section of a single CPU row in systrace. As far as I know, trace-compass already has the CPUX view, as shown in the attachment (which is a gantt cha
Hi, Thanks for the reply. Attached is a screenshot section of a single CPU row in systrace. As far as I know, trace-compass already has the CPUX view, as shown in the attachment (which is a gantt chart for a CPU X comprising of different process slices) Along with every CPUX processes row, there's also a row/gantt of the CPU's frequency and the Idle state just below the CPUX processes row. the screenshot I've attached is for CPU 0. The green plot is the CPU frequency. What systrace users are used to is the gantt chart for the processes is displayed just above the gantt chart for the Clock frequency. This lets folks correlate what's happening on the CPUs with the clock frequency and that's looked at as quite important. Hope this description is clear, let me know if you'd like me to describe it in any other way. I am also not sure what's CPU status, but if there's a way to display the "CPU status" graphically as a gantt chart (1 gantt chart row per status metric?), then that would be awesome. They key is that we need to visually know what processes were running on the CPU at the time the event happened (like the frequency was changed). Thanks a lot for your time and looking forward to trying to spread the use of trace-compass in our world ;)
Joel, could you provide a trace with CPU frequency scaling in action please? When I did something similar, the event to consider was power_cpu_frequency in lttng. I'd like to see it in a an Android trace.
Created attachment 273783 [details] cpufreq trace.html in action cpufreq trace.html in action
From the attached webpage, You can hit 'w' to zoom in, and 'a', 'd' to move left/right. 's' to zoom out. Towards the extreme right, you can see a lot of frequency scaling.
Also, what should be the minimum and maximum values? 1- Are they available somewhere in the trace? 2- Are they taken from the values they take during the trace? ie a trace that goes from values 1000 to 9000 vs a trace that goes from 7000 to 9000, the 0% would be 1000 for the first, but 7000 for the second, which gives a weird impression... 3- In Android traces, is there some metadata available to get min/max CPU frequencies for each CPU. I don't think this information is available with lttng. Those are the problems, displaying the data is the easy part ;-)
Thanks Genieve. There is a cpu_frequency_limits trace event which can be used and is there most of the time, but I think some times the event can get lost for large traces. Android AFAIK doesn't inject anything else into the trace. I am Ok if you just want to take the min as 0 and the max as some reasonable number and max = max(max-observed, 3GHz) . That should more than enough I feel.
New Gerrit change created: https://git.eclipse.org/r/121806
I did a first draft. The minimum and maximum values are per CPU, which may not be a good default, as some may be more active than others and the "0" value may not be the same for each. But if I take the min/max globally, that would look weird for big-little processors. But we gotta start somewhere. I'll try to see if we can do something with the cpu_frequency_limits information. That should be a second step though.
Gerrit change https://git.eclipse.org/r/121806 was merged to [master]. Commit: http://git.eclipse.org/c/tracecompass/org.eclipse.tracecompass.git/commit/?id=92e7849346d29e08bf8f58f8855155504deaf4ee
Genieve, thanks. I couldn't find the CPU frequency view in latest trace compass, could you let me know where to find it inside tracecompass? Also, I had created a bug for also displaying the C-state as a separate row with some screenshots: https://bugs.eclipse.org/bugs/show_bug.cgi?id=511792 So basically to bring trace-compass onpar with systrace in this regard, we would need tracecompass to show: CPU X Threads CPU X State CPU X Frequency CPU X C-state [ GAP (atleast 3 rows worth) ] CPU Y Threads CPU Y State CPU Y Frequency CPU Y C-state The C-state is essentially an integer with a range of -1 to 5. The C-state could also just be color coded (so red could mean the highest C-state (deepest idle) in the trace (C-state = 5) and green could mean non-idle (C-state = -1). Once we have this, I can market tracecompass to all our power management Android engineers in our teams and other teams :)
Reopening
Hey, I think we have the frequency working, at this point do we "just" need c-states?
