diff options
| author | Zhengyin Qian <qianzy@google.com> | 2016-05-09 11:40:18 -0700 |
|---|---|---|
| committer | Zhengyin Qian <qianzy@google.com> | 2016-05-12 22:29:36 +0000 |
| commit | 180bb7f0a8394a05622112b2f553f40bd11f9deb (patch) | |
| tree | 1a3b9ca5c11c0752251c6dfcabc47b7a0ed78d9f /ANRdaemon/README | |
| parent | faf487dfa9bf5b22fe6dd7e8696a26a2081361eb (diff) | |
| download | extras-180bb7f0a8394a05622112b2f553f40bd11f9deb.tar.gz | |
ANRdaemon: add README and a bash script to easily get trace.
Change-Id: I5c9b819a6b05003e68d26bfacccf4c539ddab7ae
Diffstat (limited to 'ANRdaemon/README')
| -rw-r--r-- | ANRdaemon/README | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/ANRdaemon/README b/ANRdaemon/README new file mode 100644 index 00000000..57ed594a --- /dev/null +++ b/ANRdaemon/README @@ -0,0 +1,30 @@ +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: +$ ANRdaemon -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. |