Docs: fix typos

Original patch from
https://github.com/scottwedge/perfetto/commit/0b6e31898fa8f53b377e9495770ae0814bf17dc2

Change-Id: I6f30f7ee7c21eb5f7615b91e5ba898b70bfe13f5

docs/README.md

diff --git a/docs/README.md b/docs/README.md
index 76d53d4..bec4a7e 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -58,7 +58,7 @@
 
 On Android, Perfetto is the next-generation system tracing system and replaces
 the chromium-based systrace.
-[ATrace-based intstrumentation](/docs/data-sources/atrace.md) remains fully
+[ATrace-based instrumentation](/docs/data-sources/atrace.md) remains fully
 supported.
 See [Android developer docs](https://developer.android.com/topic/performance/tracing)
 for more details.

docs/analysis/trace-processor.md

diff --git a/docs/analysis/trace-processor.md b/docs/analysis/trace-processor.md
index 226afd3..1214d59 100644
--- a/docs/analysis/trace-processor.md
+++ b/docs/analysis/trace-processor.md
@@ -245,7 +245,7 @@
 ```
 
 ## Operator tables
-SQL queries are usually sufficient to retrieive data from trace processor.
+SQL queries are usually sufficient to retrieve data from trace processor.
 Sometimes though, certain constructs can be difficult to express pure SQL.
 
 In these situations, trace processor has special "operator tables" which solve

docs/concepts/buffers.md

diff --git a/docs/concepts/buffers.md b/docs/concepts/buffers.md
index 2764858..2a8012c 100644
--- a/docs/concepts/buffers.md
+++ b/docs/concepts/buffers.md
@@ -347,7 +347,7 @@
    [`TraceConfig.IncrementalStateConfig.clear_period_ms`][IncrStateConfig].
    This will cause the data sources that make use of incremental state to
    periodically drop the interning / process mapping tables and re-emit the
-   descriptors / strings on the next occurence. This mitigates quite well the
+   descriptors / strings on the next occurrence. This mitigates quite well the
    problem in the context of ring-buffer traces, as long as the
    `clear_period_ms` is one order of magnitude lower than the estimated length
    of trace data in the central trace buffer.
@@ -363,15 +363,15 @@
 Another common problem experienced in traces that involve multiple data sources
 is the non-synchronous nature of trace commits. As explained in the
 [Life of a trace packet](#life-of-a-trace-packet) section above, trace data is
-commited only when a full memory page of the shared memory buffer is filled (or
+committed only when a full memory page of the shared memory buffer is filled (or
 at when the tracing session ends). In most cases, if data sources produce events
 at a regular cadence, pages are filled quite quickly and events are committed
 in the central buffers within seconds.
 
 In some other cases, however, a data source can emit events only sporadically.
 Imagine the case of a data source that emits events when the display is turned
-on/off. Such an infequent event might end up being staged in the shared memory
-buffer for very long times and can end up being commited in the trace buffer
+on/off. Such an infrequent event might end up being staged in the shared memory
+buffer for very long times and can end up being committed in the trace buffer
 hours after it happened.
 
 Another scenario where this can happen is when using ftrace and when a
@@ -419,4 +419,4 @@
 [FtraceCpuStats]: /docs/reference/trace-packet-proto.autogen#FtraceCpuStats
 [FtraceEventBundle]: /docs/reference/trace-packet-proto.autogen#FtraceEventBundle
 [TracePacket]: /docs/reference/trace-packet-proto.autogen#TracePacket
-[BufferStats]: /docs/reference/trace-packet-proto.autogen#TraceStats.BufferStats
\ No newline at end of file
+[BufferStats]: /docs/reference/trace-packet-proto.autogen#TraceStats.BufferStats