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