simpleperf: fix some format error in README.md.

Test: none
Change-Id: Ibc11990dc511fcf7eafc91becdb0383e4fb186e2

2 files changed, 145 insertions, 140 deletions

diff --git a/simpleperf/README.md b/simpleperf/README.md
index b6dc9d79..1ac99ef0 100644
--- a/simpleperf/README.md
+++ b/simpleperf/README.md
@@ -149,10 +149,10 @@ important subcommands and options. To see all subcommands and options,
 use --help.
 
     # List all subcommands.
-    $simpleperf --help
+    $ simpleperf --help
 
     # Print help message for record subcommand.
-    $simpleperf record --help
+    $ simpleperf record --help
 
 
 #### Simpleperf list
@@ -161,7 +161,7 @@ simpleperf list is used to list all events available on the device. Different
 devices may support different events because of differences in hardware and
 kernel.
 
-    $simpleperf list
+    $ simpleperf list
     List of hw-cache events:
       branch-loads
       ...
@@ -184,7 +184,7 @@ Below is an example.
 
     # Stat using default events (cpu-cycles,instructions,...), and monitor
     # process 7394 for 10 seconds.
-    $simpleperf stat -p 7394 --duration 10
+    $ simpleperf stat -p 7394 --duration 10
     Performance counter statistics:
 
      1,320,496,145  cpu-cycles         # 0.131736 GHz                     (100%)
@@ -200,10 +200,10 @@ Below is an example.
 We can select which events to use via -e option. Below are examples:
 
     # Stat event cpu-cycles.
-    $simpleperf stat -e cpu-cycles -p 11904 --duration 10
+    $ simpleperf stat -e cpu-cycles -p 11904 --duration 10
 
     # Stat event cache-references and cache-misses.
-    $simpleperf stat -e cache-references,cache-misses -p 11904 --duration 10
+    $ simpleperf stat -e cache-references,cache-misses -p 11904 --duration 10
 
 When running the stat command, if the number of hardware events is larger than
 the number of hardware counters available in the PMU, the kernel shares hardware
@@ -212,7 +212,7 @@ time. In the example below, there is a percentage at the end of each row,
 showing the percentage of the total time that each event was actually monitored.
 
     # Stat using event cache-references, cache-references:u,....
-    $simpleperf stat -p 7394 -e     cache-references,cache-references:u,cache-references:k,cache-misses,cache-misses:u,cache-misses:k,instructions --duration 1
+    $ simpleperf stat -p 7394 -e     cache-references,cache-references:u,cache-references:k,cache-misses,cache-misses:u,cache-misses:k,instructions --duration 1
     Performance counter statistics:
 
     4,331,018  cache-references     # 4.861 M/sec    (87%)
@@ -231,7 +231,7 @@ time. If we want to have some events monitored at the same time, we can use
 --group option. Below is an example.
 
     # Stat using event cache-references, cache-references:u,....
-    $simpleperf stat -p 7394 --group cache-references,cache-misses --group cache-references:u,cache-misses:u --group cache-references:k,cache-misses:k -e instructions --duration 1
+    $ simpleperf stat -p 7394 --group cache-references,cache-misses --group cache-references:u,cache-misses:u --group cache-references:k,cache-misses:k -e instructions --duration 1
     Performance counter statistics:
 
     3,638,900  cache-references     # 4.786 M/sec          (74%)
@@ -251,13 +251,13 @@ Simpleperf can also fork a child process to run the new command and then monitor
 the child process. Below are examples.
 
     # Stat process 11904 and 11905.
-    $simpleperf stat -p 11904,11905 --duration 10
+    $ simpleperf stat -p 11904,11905 --duration 10
 
     # Stat thread 11904 and 11905.
-    $simpleperf stat -t 11904,11905 --duration 10
+    $ simpleperf stat -t 11904,11905 --duration 10
 
     # Start a child process running `ls`, and stat it.
-    $simpleperf stat ls
+    $ simpleperf stat ls
 
 **Decide how long to monitor**
 When monitoring existing threads, we can use --duration option to decide how long
@@ -266,13 +266,13 @@ monitors until the child process ends. In this case, we can use Ctrl-C to stop m
 at any time. Below are examples.
 
     # Stat process 11904 for 10 seconds.
-    $simpleperf stat -p 11904 --duration 10
+    $ simpleperf stat -p 11904 --duration 10
 
     # Stat until the child process running `ls` finishes.
-    $simpleperf stat ls
+    $ simpleperf stat ls
 
     # Stop monitoring using Ctrl-C.
-    $simpleperf stat -p 11904 --duration 10
+    $ simpleperf stat -p 11904 --duration 10
     ^C
 
 **Decide the print interval**
@@ -280,20 +280,20 @@ When monitoring perf counters, we can also use --interval option to decide the p
 interval. Below are examples.
 
     # Print stat for process 11904 every 300ms.
-    $simpleperf stat -p 11904 --duration 10 --interval 300
+    $ simpleperf stat -p 11904 --duration 10 --interval 300
 
     # Print system wide stat at interval of 300ms for 10 seconds (rooted device only).
     # system wide profiling needs root privilege
-    $su 0 simpleperf stat -a --duration 10 --interval 300
+    $ su 0 simpleperf stat -a --duration 10 --interval 300
 
 **Display counters in systrace**
 simpleperf can also work with systrace to dump counters in the collected trace.
 Below is an example to do a system wide stat
 
     # capture instructions (kernel only) and cache misses with interval of 300 milliseconds for 15 seconds
-    $su 0 simpleperf stat -e instructions:k,cache-misses -a --interval 300 --duration 15
+    $ su 0 simpleperf stat -e instructions:k,cache-misses -a --interval 300 --duration 15
     # on host launch systrace to collect trace for 10 seconds
-    (HOST)$external/chromium-trace/systrace.py --time=10 -o new.html sched gfx view
+    (HOST)$ external/chromium-trace/systrace.py --time=10 -o new.html sched gfx view
     # open the collected new.html in browser and perf counters will be shown up
 
 
@@ -306,7 +306,7 @@ what frequency to dump records, how long to monitor, and where to store records.
     # Record on process 7394 for 10 seconds, using default event (cpu-cycles),
     # using default sample frequency (4000 samples per second), writing records
     # to perf.data.
-    $simpleperf record -p 7394 --duration 10
+    $ simpleperf record -p 7394 --duration 10
     simpleperf I 07-11 21:44:11 17522 17522 cmd_record.cpp:316] Samples recorded: 21430. Samples lost: 0.
 
 **Select events**
@@ -315,20 +315,20 @@ As a hardware event, it is both accurate and efficient. We can also use other
 events via -e option. Below is an example.
 
     # Record using event instructions.
-    $simpleperf record -e instructions -p 11904 --duration 10
+    $ simpleperf record -e instructions -p 11904 --duration 10
 
 **Select target to monitor**
 The way to select target in record command is similar to that in stat command.
 Below are examples.
 
     # Record process 11904 and 11905.
-    $simpleperf record -p 11904,11905 --duration 10
+    $ simpleperf record -p 11904,11905 --duration 10
 
     # Record thread 11904 and 11905.
-    $simpleperf record -t 11904,11905 --duration 10
+    $ simpleperf record -t 11904,11905 --duration 10
 
     # Record a child process running `ls`.
-    $simpleperf record ls
+    $ simpleperf record ls
 
 **Set the frequency to record**
 We can set the frequency to dump records via the -f or -c options. For example,
@@ -339,23 +339,23 @@ records every second. Another way is using -c option. For example, -c 10000
 means dumping one record whenever 10000 events happen. Below are examples.
 
     # Record with sample frequency 1000: sample 1000 times every second running.
-    $simpleperf record -f 1000 -p 11904,11905 --duration 10
+    $ simpleperf record -f 1000 -p 11904,11905 --duration 10
 
     # Record with sample period 100000: sample 1 time every 100000 events.
-    $simpleperf record -c 100000 -t 11904,11905 --duration 10
+    $ simpleperf record -c 100000 -t 11904,11905 --duration 10
 
 **Decide how long to monitor**
 The way to decide how long to monitor in record command is similar to that in
 stat command. Below are examples.
 
     # Record process 11904 for 10 seconds.
-    $simpleperf record -p 11904 --duration 10
+    $ simpleperf record -p 11904 --duration 10
 
     # Record until the child process running `ls` finishes.
-    $simpleperf record ls
+    $ simpleperf record ls
 
     # Stop monitoring using Ctrl-C.
-    $simpleperf record -p 11904 --duration 10
+    $ simpleperf record -p 11904 --duration 10
     ^C
 
 **Set the path to store records**
@@ -363,7 +363,7 @@ By default, simpleperf stores records in perf.data in current directory. We can
 use -o option to set the path to store records. Below is an example.
 
     # Write records to data/perf2.data.
-    $simpleperf record -p 11904 -o data/perf2.data --duration 10
+    $ simpleperf record -p 11904 -o data/perf2.data --duration 10
 
 
 #### Simpleperf report
@@ -385,7 +385,7 @@ time used in each function.
     # Reports perf.data, using only records sampled in libsudo-game-jni.so,
     # grouping records using thread name(comm), process id(pid), thread id(tid),
     # function name(symbol), and showing sample count for each row.
-    $simpleperf report --dsos /data/app/com.example.sudogame-2/lib/arm64/libsudo-game-jni.so --sort comm,pid,tid,symbol -n
+    $ simpleperf report --dsos /data/app/com.example.sudogame-2/lib/arm64/libsudo-game-jni.so --sort comm,pid,tid,symbol -n
     Cmdline: /data/data/com.example.sudogame/simpleperf record -p 7394 --duration 10
     Arch: arm64
     Event: cpu-cycles (type 0, config 0)
@@ -402,7 +402,7 @@ time used in each function.
 By default, simpleperf reads perf.data in current directory. We can use -i
 option to select another file to read records.
 
-    $simpleperf report -i data/perf2.data
+    $ simpleperf report -i data/perf2.data
 
 **Set the path to find executable binaries**
 If reporting function symbols, simpleperf needs to read executable binaries
@@ -412,11 +412,11 @@ recording. However, these binaries may not exist when reporting or not contain
 symbol table and debug information. So we can use --symfs to redirect the paths.
 Below is an example.
 
-    $simpleperf report
+    $ simpleperf report
     # In this case, when simpleperf wants to read executable binary /A/b,
     # it reads file in /A/b.
 
-    $simpleperf report --symfs /debug_dir
+    $ simpleperf report --symfs /debug_dir
     # In this case, when simpleperf wants to read executable binary /A/b,
     # it prefers file in /debug_dir/A/b to file in /A/b.
 
@@ -425,19 +425,19 @@ When reporting, it happens that not all records are of interest. Simpleperf
 supports five filters to select records of interest. Below are examples.
 
     # Report records in threads having name sudogame.
-    $simpleperf report --comms sudogame
+    $ simpleperf report --comms sudogame
 
     # Report records in process 7394 or 7395
-    $simpleperf report --pids 7394,7395
+    $ simpleperf report --pids 7394,7395
 
     # Report records in thread 7394 or 7395.
-    $simpleperf report --tids 7394,7395
+    $ simpleperf report --tids 7394,7395
 
     # Report records in libsudo-game-jni.so.
-    $simpleperf report --dsos /data/app/com.example.sudogame-2/lib/arm64/libsudo-game-jni.so
+    $ simpleperf report --dsos /data/app/com.example.sudogame-2/lib/arm64/libsudo-game-jni.so
 
     # Report records in function checkValid or canFindSolution_r.
-    $simpleperf report --symbols "checkValid(Board const&, int, int);canFindSolution_r(Board&, int, int)"
+    $ simpleperf report --symbols "checkValid(Board const&, int, int);canFindSolution_r(Board&, int, int)"
 
 **Decide how to group records into sample entries**
 Simpleperf uses --sort option to decide how to group sample entries. Below are
@@ -445,26 +445,26 @@ examples.
 
     # Group records based on their process id: records having the same process
     # id are in the same sample entry.
-    $simpleperf report --sort pid
+    $ simpleperf report --sort pid
 
     # Group records based on their thread id and thread comm: records having
     # the same thread id and thread name are in the same sample entry.
-    $simpleperf report --sort tid,comm
+    $ simpleperf report --sort tid,comm
 
     # Group records based on their binary and function: records in the same
     # binary and function are in the same sample entry.
-    $simpleperf report --sort dso,symbol
+    $ simpleperf report --sort dso,symbol
 
     # Default option: --sort comm,pid,tid,dso,symbol. Group records in the same
     # thread, and belong to the same function in the same binary.
-    $simpleperf report
+    $ simpleperf report
 
 
 ## Android application profiling
 
 This section shows how to profile an Android application.
 [Here](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/README.md) are examples. And we use
-[SimpleperfExamplePureJava]((https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava) project to show the profiling results.
+[SimpleperfExamplePureJava](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava) project to show the profiling results.
 
 Simpleperf only supports profiling native instructions in binaries in ELF
 format. If the Java code is executed by interpreter, or with jit cache, it
@@ -501,32 +501,32 @@ the jvm running in oat mode, which is only available >= L.
 To profile Java code, we need the jvm running in oat mode. But on Android O,
 debuggable applications are forced to run in jit mode. To work around this,
 we need to add a `wrap.sh` in the apk. So if you are running on Android O device,
-Check [here]((https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
+Check [here](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
 for how to add `wrap.sh` in the apk.
 
 **4. Make sure C++ code is compiled with optimizing flags.**
 If the application contains C++ code, it can be compiled with -O0 flag in debug build type.
-This makes C++ code slow. Check [here]((https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
+This makes C++ code slow. Check [here](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
 for how to avoid that.
 
 **5. Use native libraries with debug info in the apk when possible.**
 If the application contains C++ code or pre-compiled native libraries, try to use
 unstripped libraries in the apk. This helps simpleperf generating better profiling
-results. Check [here]((https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
+results. Check [here](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava/app/profiling.gradle)
 for how to use unstripped libraries.
 
-Here we use [SimpleperfExamplePureJava]((https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava) as an example.
+Here we use [SimpleperfExamplePureJava](https://android.googlesource.com/platform/system/extras/+/master/simpleperf/demo/SimpleperfExamplePureJava) as an example.
 It builds an app-profiling.apk for profiling.
 
-    $git clone https://android.googlesource.com/platform/system/extras
-    $cd extras/simpleperf/demo
+    $ git clone https://android.googlesource.com/platform/system/extras
+    $ cd extras/simpleperf/demo
     # Open SimpleperfExamplesPureJava project with Android studio,
     # and build this project sucessfully, otherwise the `./gradlew` command below will fail.
-    $cd SimpleperfExamplePureJava
+    $ cd SimpleperfExamplePureJava
 
     # On windows, use "gradlew" instead.
-    $./gradlew clean assemble
-    $adb install -r app/build/outputs/apk/app-profiling.apk
+    $ ./gradlew clean assemble
+    $ adb install -r app/build/outputs/apk/app-profiling.apk
 
 
 ### Record and report profiling data (using command-lines)
@@ -537,7 +537,7 @@ step by step. So we first show how to use command lines.
 
 **1. Enable profiling**
 
-    $adb shell setprop security.perf_harden 0
+    $ adb shell setprop security.perf_harden 0
 
 **2. Fully compile the app**
 
@@ -546,10 +546,10 @@ in the application. This needs different commands on different Android versions.
 
 On Android >= N:
 
-    $adb shell setprop debug.generate-debug-info true
-    $adb shell cmd package compile -f -m speed com.example.simpleperf.simpleperfexamplepurejava
+    $ adb shell setprop debug.generate-debug-info true
+    $ adb shell cmd package compile -f -m speed com.example.simpleperf.simpleperfexamplepurejava
     # Restart the app to take effect
-    $adb shell am force-stop com.example.simpleperf.simpleperfexamplepurejava
+    $ adb shell am force-stop com.example.simpleperf.simpleperfexamplepurejava
 
 On Android M devices, We need root privilege to force Android to fully compile
 Java code into native instructions in ELF binaries with debug information. We
@@ -557,29 +557,29 @@ also need root privilege to read compiled native binaries (because installd
 writes them to a directory whose uid/gid is system:install). So profiling Java
 code can only be done on rooted devices.
 
-    $adb root
-    $adb shell setprop dalvik.vm.dex2oat-flags -g
+    $ adb root
+    $ adb shell setprop dalvik.vm.dex2oat-flags -g
 
     # Reinstall the app.
-    $adb install -r app/build/outputs/apk/app-profiling.apk
+    $ adb install -r app/build/outputs/apk/app-profiling.apk
 
 On Android L devices, we also need root privilege to compile the app with debug info
 and access the native binaries.
 
-    $adb root
-    $adb shell setprop dalvik.vm.dex2oat-flags --include-debug-symbols
+    $ adb root
+    $ adb shell setprop dalvik.vm.dex2oat-flags --include-debug-symbols
 
     # Reinstall the app.
-    $adb install -r app/build/outputs/apk/app-profiling.apk
+    $ adb install -r app/build/outputs/apk/app-profiling.apk
 
 
 **3. Find the app process**
 
     # Start the app if needed
-    $adb shell am start -n com.example.simpleperf.simpleperfexamplepurejava/.MainActivity
+    $ adb shell am start -n com.example.simpleperf.simpleperfexamplepurejava/.MainActivity
 
     # Run `ps` in the app's context. On Android >= O devicces, run `ps -e` instead.
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ps | grep simpleperf
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ps | grep simpleperf
     u0_a151   6885  3346  1590504 53980 SyS_epoll_ 6fc2024b6c S com.example.simpleperf.simpleperfexamplepurejava
 
 So the id of the app process is `6885`. We will use this number in the command lines below,
@@ -588,22 +588,22 @@ please replace this number with what you get by running `ps` command.
 **4. Download simpleperf to the app's data directory**
 
     # Find which architecture the app is using.
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cat /proc/6885/maps | grep boot.oat
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cat /proc/6885/maps | grep boot.oat
     708e6000-70e33000 r--p 00000000 103:09 1214                              /system/framework/arm64/boot.oat
 
     # The app uses /arm64/boot.oat, so push simpleperf in bin/android/arm64/ to device.
-    $cd ../../scripts/
-    $adb push bin/android/arm64/simpleperf /data/local/tmp
-    $adb shell chmod a+x /data/local/tmp/simpleperf
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cp /data/local/tmp/simpleperf .
+    $ cd ../../scripts/
+    $ adb push bin/android/arm64/simpleperf /data/local/tmp
+    $ adb shell chmod a+x /data/local/tmp/simpleperf
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cp /data/local/tmp/simpleperf .
 
 
 **5. Record perf.data**
 
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record -p 6885 --duration 10 --dump-symbols
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record -p 6885 --duration 10 --dump-symbols
     simpleperf I 04-27 20:41:11  6940  6940 cmd_record.cpp:357] Samples recorded: 40008. Samples lost: 0.
 
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ls -lh perf.data
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ls -lh perf.data
     simpleperf I 04-27 20:31:40  5999  5999 cmd_record.cpp:357] Samples recorded: 39949. Samples lost: 0.
 
 The profiling data is recorded at perf.data.
@@ -617,11 +617,11 @@ There are many options to record profiling data, check [record command](#simplep
 **6. Report perf.data**
 
     # Pull perf.data on host.
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cat perf.data >perf.data
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava cat perf.data >perf.data
 
     # Report samples using corresponding simpleperf executable on host.
     # On windows, use "bin\windows\x86_64\simpleperf" instead.
-    $bin/linux/x86_64/simpleperf report
+    $ bin/linux/x86_64/simpleperf report
     ...
     Overhead  Command   Pid   Tid   Shared Object                                                                     Symbol
     83.54%    Thread-2  6885  6900  /data/app/com.example.simpleperf.simpleperfexamplepurejava-2/oat/arm64/base.odex  void com.example.simpleperf.simpleperfexamplepurejava.MainActivity$1.run()
@@ -653,7 +653,7 @@ application. It is not necessary for profiling.
 
 **2. Run `app-profiler.py`**
 
-    $python app_profiler.py
+    $ python app_profiler.py
 
 
 If running successfully, it will collect profiling data in perf.data in current
@@ -663,7 +663,7 @@ directory, and related native binaries in binary_cache/.
 
 We can use `report.py` to report perf.data.
 
-    $python report.py
+    $ python report.py
 
 We can add any option accepted by `simpleperf report` command to `report.py`.
 
@@ -693,7 +693,7 @@ A call graph is a tree showing function call relations. Below is an example.
 
 When using command lines, add `-g` option like below:
 
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record -g -p 6685 --duration 10 --dump-symbols
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record -g -p 6685 --duration 10 --dump-symbols
 
 When using python scripts, change `app-profiler.config` as below:
 
@@ -708,7 +708,7 @@ it is better to contain non-stripped native libraries in the apk.
 
 When using command lines, add `--call-graph fp` option like below:
 
-    $adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record --call-graph fp -p 6685 --duration 10 --dump-symbols
+    $ adb shell run-as com.example.simpleperf.simpleperfexamplepurejava ./simpleperf record --call-graph fp -p 6685 --duration 10 --dump-symbols
 
 When using python scripts, change `app-profiler.config` as below:
 
@@ -726,7 +726,7 @@ architecture, or profiling in arm64 environment.**
 
 To report call graph using command lines, add `-g --brief-callgraph` option.
 
-    $bin/linux/x86_64/simpleperf report -g --brief-callgraph
+    $ bin/linux/x86_64/simpleperf report -g --brief-callgraph
     ...
     Children  Self    Command          Pid    Tid    Shared Object                                                                     Symbol
     99.97%    0.00%   Thread-2         10859  10876  /system/framework/arm64/boot.oat                                                  java.lang.Thread.run
@@ -741,7 +741,7 @@ To report call graph using command lines, add `-g --brief-callgraph` option.
 
 To report call graph using python scripts, add `-g` option.
 
-    $python report.py -g
+    $ python report.py -g
     # Double-click an item started with '+' to show its callgraph.
 
 ### Visualize profiling data
@@ -753,9 +753,9 @@ to other formats. Below are two examples.
 
 ### Show flamegraph
 
-    $python report_sample.py >out.perf
-    $stackcollapse-perf.pl out.perf >out.folded
-    $./flamegraph.pl out.folded >a.svg
+    $ python report_sample.py >out.perf
+    $ stackcollapse-perf.pl out.perf >out.folded
+    $ ./flamegraph.pl out.folded >a.svg
 
 
 ### Visualize using pprof
@@ -764,8 +764,8 @@ pprof is a tool for visualization and analysis of profiling data. It can
 be got from https://github.com/google/pprof. pprof_proto_generator.py can
 generate profiling data in a format acceptable by pprof.
 
-    $python pprof_proto_generator.py
-    $pprof -pdf pprof.profile
+    $ python pprof_proto_generator.py
+    $ pprof -pdf pprof.profile
 
 
 ### Annotate source code
@@ -786,7 +786,7 @@ in PATH environment variable.
 
 **2. Run `annotate.py`**
 
-    $python annotate.py
+    $ python annotate.py
 
 
 **3. Read annotated code**
diff --git a/simpleperf/demo/README.md b/simpleperf/demo/README.md
index 3737416d..e17c27d8 100644
--- a/simpleperf/demo/README.md
+++ b/simpleperf/demo/README.md
@@ -20,8 +20,8 @@ meaning of each directory is as below:
 
 It can be downloaded as below:
 
-    $git clone https://android.googlesource.com/platform/system/extras
-    $cd extras/simpleperf/demo
+    $ git clone https://android.googlesource.com/platform/system/extras
+    $ cd extras/simpleperf/demo
 
 ## Profiling Java application
 
@@ -31,37 +31,40 @@ It can be downloaded as below:
 
 steps:
 1. Build and install app:
+```
+# Open SimpleperfExamplesPureJava project with Android Studio,
+# and build this project sucessfully, otherwise the `./gradlew` command below will fail.
+$ cd SimpleperfExamplePureJava
 
-    # Open SimpleperfExamplesPureJava project with Android Studio,
-    # and build this project sucessfully, otherwise the `./gradlew` command below will fail.
-    $cd SimpleperfExamplePureJava
-
-    # On windows, use "gradlew" instead.
-    $./gradlew clean assemble
-    $adb install -r app/build/outputs/apk/app-profiling.apk
+# On windows, use "gradlew" instead.
+$ ./gradlew clean assemble
+$ adb install -r app/build/outputs/apk/app-profiling.apk
+```
 
 2. Record profiling data:
-
-    $cd ../../scripts/
-    $gvim app_profiler.config
-      change app_package_name line to: app_package_name = "com.example.simpleperf.simpleperfexamplepurejava"
-    $python app_profiler.py
-      It runs the application and collects profiling data in perf.data, binaries on device in binary_cache/.
+```
+$ cd ../../scripts/
+$ gvim app_profiler.config
+    change app_package_name line to: app_package_name = "com.example.simpleperf.simpleperfexamplepurejava"
+$ python app_profiler.py
+    It runs the application and collects profiling data in perf.data, binaries on device in binary_cache/.
+```
 
 3. Show profiling data:
-
-    a. show call graph in txt mode
-        # On windows, use "bin\windows\x86\simpleperf" instead.
-        $bin/linux/x86_64/simpleperf report -g --brief-callgraph | more
-          If on other hosts, use corresponding simpleperf binary.
-    b. show call graph in gui mode
-        $python report.py -g
-    c. show samples in source code
-        $gvim annotate.config
-          change source_dirs line to: source_dirs = ["../demo/SimpleperfExamplePureJava"]
-        $python annotate.py
-        $gvim annotated_files/java/com/example/simpleperf/simpleperfexamplepurejava/MainActivity.java
-          check the annoated source file MainActivity.java.
+```
+a. show call graph in txt mode
+    # On windows, use "bin\windows\x86\simpleperf" instead.
+    $ bin/linux/x86_64/simpleperf report -g --brief-callgraph | more
+        If on other hosts, use corresponding simpleperf binary.
+b. show call graph in gui mode
+    $ python report.py -g
+c. show samples in source code
+    $ gvim annotate.config
+        change source_dirs line to: source_dirs = ["../demo/SimpleperfExamplePureJava"]
+    $ python annotate.py
+    $ gvim annotated_files/java/com/example/simpleperf/simpleperfexamplepurejava/MainActivity.java
+        check the annoated source file MainActivity.java.
+```
 
 ## Profiling Java/C++ application
 
@@ -71,35 +74,37 @@ steps:
 
 steps:
 1. Build and install app:
+```
+# Open SimpleperfExamplesPureJava project with Android Studio,
+# and build this project sucessfully, otherwise the `./gradlew` command below will fail.
+$ cd SimpleperfExampleWithNative
 
-    # Open SimpleperfExamplesPureJava project with Android Studio,
-    # and build this project sucessfully, otherwise the `./gradlew` command below will fail.
-    $cd SimpleperfExampleWithNative
-
-    # On windows, use "gradlew" instead.
-    $./gradlew clean assemble
-    $adb install -r app/build/outputs/apk/app-profiling.apk
+# On windows, use "gradlew" instead.
+$ ./gradlew clean assemble
+$ adb install -r app/build/outputs/apk/app-profiling.apk
+```
 
 2. Record profiling data:
-
-    $cd ../../scripts/
-    $gvim app_profiler.config
-      change app_package_name line to: app_package_name = "com.example.simpleperf.simpleperfexamplewithnative"
-    $python app_profiler.py
-      It runs the application and collects profiling data in perf.data, binaries on device in binary_cache/.
+```
+$ cd ../../scripts/
+$ gvim app_profiler.config
+    change app_package_name line to: app_package_name = "com.example.simpleperf.simpleperfexamplewithnative"
+$ python app_profiler.py
+    It runs the application and collects profiling data in perf.data, binaries on device in binary_cache/.
+```
 
 3. Show profiling data:
-
-    a. show call graph in txt mode
-        # On windows, use "bin\windows\x86\simpleperf" instead.
-        $bin/linux/x86_64/simpleperf report -g --brief-callgraph | more
-          If on other hosts, use corresponding simpleperf binary.
-    b. show call graph in gui mode
-        $python report.py -g
-    c. show samples in source code
-        $gvim annotate.config
-          change source_dirs line to: source_dirs = ["../demo/SimpleperfExampleWithNative"]
-        $python annotate.py
-        $find . -name "native-lib.cpp" | xargs gvim
-          check the annoated source file native-lib.cpp.
-
+```
+a. show call graph in txt mode
+    # On windows, use "bin\windows\x86\simpleperf" instead.
+    $ bin/linux/x86_64/simpleperf report -g --brief-callgraph | more
+        If on other hosts, use corresponding simpleperf binary.
+b. show call graph in gui mode
+    $ python report.py -g
+c. show samples in source code
+    $ gvim annotate.config
+        change source_dirs line to: source_dirs = ["../demo/SimpleperfExampleWithNative"]
+    $ python annotate.py
+    $ find . -name "native-lib.cpp" | xargs gvim
+        check the annoated source file native-lib.cpp.
+```
\ No newline at end of file