OSDN Git Service

Merge "procrank: fix bounds check to prevent heap overflow" into nyc-mr1-dev
[android-x86/system-extras.git] / ANRdaemon / README
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:
10 $ ANRdaemon -t 9990 sched gfx am
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.