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