31 lines
1.7 KiB
Plaintext
31 lines
1.7 KiB
Plaintext
ANRdaemon is a daemon to help analyze ANR due to CPU starvation by logging system
|
|
activity when CPU usage is very high. The daemon uses debugfs underlying for
|
|
logging. Trace are configured ahead by setting different modules in /d/tracing.
|
|
Depending on the CPU usage level, the trace is turn on/off by writting to the
|
|
global control /d/trace/trace_on. The raw trace file is stored at
|
|
/d/tracing/trace.
|
|
|
|
The daemon will be started at boot time and will be running with the following
|
|
settings:
|
|
$ anrd -t 9990 sched gfx am
|
|
This means tracing will be enabled above 99.90% CPU utilization and will trace
|
|
sched, gfx and am modules (See -h for more info).
|
|
|
|
Use ANRdaemon_get_trace.sh [device serial] to dump and fetch the compressed trace file.
|
|
|
|
The compressed trace file can be parsed using systrace:
|
|
$ systrace.py --from-file=<path to compressed trace file>
|
|
|
|
Known issue: in the systrace output, anrdaemon will show up when the trace is
|
|
not running. This is because the daemon process turns off tracing when CPU usage
|
|
drops, the last entry it leaves in the raw trace file is the scheduler switched
|
|
from some other process to the daemon. Then sometime later (say 20 secs later),
|
|
when the CPU usage becomes high and the daemon process turn on tracing again,
|
|
the first entry in /d/tracing/trace logged by sched is switching away from the
|
|
daemon process to some other process. Due to this artifact, when the raw trace
|
|
file is parsed by systrace.py, the daemon process is shown as running for the
|
|
whole 20secs (because from systrace's view, the two 20 sec apart sched trace
|
|
entries regarding the daemon process indicates the daemon process ran continuously
|
|
for all 20sec). However, this will not affect the actual captured trace during
|
|
high CPU usage case.
|