| 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. |