On 30/01/2015 00:59, David Flanagan wrote: > I've recently been investigating some app startup time issues on > quad-core devices (like the nexus 5) and needed a way to find out how > good the Gallery app is at using all the available cores when it starts up. > > I ended up writing a python script that uses adb to read /proc/stat from > the connected device, then wait 5 seconds, then read it again. By > subtracting the first set of numbers from the second set, I can figure > out how busy or idle each core was during the 5 second wait.
If you want more detailed information on which task run on which core
you might want to try the kernel ftrace facility which is available on
the Flame.
You can start it with the following commands (on the device):
echo 1 >/sys/kernel/debug/tracing/events/sched/sched_stat_runtime/enable
echo 1 >/sys/kernel/debug/tracing/tracing_enabled
Then wait as much as you need and turn it off again:
echo 0 >/sys/kernel/debug/tracing/events/sched/sched_stat_runtime/enable
echo 0 >/sys/kernel/debug/tracing/tracing_enabled
Now you can dump the trace with:
cat /sys/kernel/debug/tracing/trace
You'll get a printout more or less like this:
# tracer: nop
#
# entries-in-buffer/entries-written: 27588/31644 #P:1
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
b2g-4841 [000] d.h3 5811.437103: sched_stat_runtime:
comm=b2g pid=4841 runtime=2058229 [ns] vruntime=1410486014383 [ns]
Timer-4867 [000] d..3 5811.437369: sched_stat_runtime:
comm=Timer pid=4867 runtime=275521 [ns] vruntime=1410481289904 [ns]
b2g-4841 [000] d.h2 5811.438856: sched_stat_runtime:
comm=b2g pid=4841 runtime=1482604 [ns] vruntime=1410487496987 [ns]
b2g-4841 [000] d..5 5811.443808: sched_stat_runtime:
comm=b2g pid=4841 runtime=4953854 [ns] vruntime=1410492450841 [ns]
Gecko_IOThread-4853 [000] d..4 5811.444165: sched_stat_runtime:
comm=Gecko_IOThread pid=4853 runtime=357760 [ns] vruntime=1410481761944 [ns]
...
Every line will contain the runtime of a single thread complete with the
process name it belongs to (or the thread name if it has one), it's PID,
the CPU on which it run (the column between square brackets) as well as
how long it executed in ns (the runtime parameter).
It should be relatively easy to aggregate this data on a per-B2G
application basis and display how much CPU time an app consumed on every
core.
Clearing the trace is just a matter of running:
echo > /sys/kernel/debug/tracing/trace
Vivien had started hacking on a script for this in bug 1061969 [1], you
might want to have a look there if you feel this might be useful.
Gabriele
[1] [Camera] Pulling down the status bar while in the camera app is very
sluggish
https://bugzilla.mozilla.org/show_bug.cgi?id=1061969
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
