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