Add documentation in memory_benchmarks.md on finding links to trace files

docs/memory-infra/memory_benchmarks.md

Index: docs/memory-infra/memory_benchmarks.md
diff --git a/docs/memory-infra/memory_benchmarks.md b/docs/memory-infra/memory_benchmarks.md
index a18158858e5108b13da539c212abcd126e4a0d32..6bf8953a1a297743cba435af138688837e31f4a6 100644
--- a/docs/memory-infra/memory_benchmarks.md
+++ b/docs/memory-infra/memory_benchmarks.md
@@ -92,6 +92,12 @@ To view data from one of the benchmarks on the
 *   **Subtest (3):** The name of a *[user story](#User-stories)*
     (with `:` replaced by `_`).
 
+If you are investigating a Perf dashboard alert and would like to see the
+details, you can click on any point of the graph. It gives you the commit range,
+buildbot output and a link to the trace file taken during the buildbot run.
+
+![Chrome Performance Dashboard Alert](https://storage.googleapis.com/chromium-docs.appspot.com/perfdashboard_alert.png)

[xunjieli, 2017/06/22 15:55:14]

Primiano: should I rename the filename to contain a hash of some sort to be
consistent with the naming convention? How did you do it?

The gsutil directory seems to have files named after hashes. 
current files are:
gs://chromium-docs.appspot.com/79d08f59cf497c761f7099ea427704c14e9afc03.png
gs://chromium-docs.appspot.com/802141906869cd533bb613da5f91bd0b071ceb24
gs://chromium-docs.appspot.com/a24d80d6a08da088e2e9c8b2b64daa215be4dacb
gs://chromium-docs.appspot.com/a325c4426422e53394a322d31b652cfa34231189
gs://chromium-docs.appspot.com/a73239c6367ed0f844500e51ce1e04556cb99b4f.png
gs://chromium-docs.appspot.com/ea60207d9bb4809178fe75923d6d1a2b241170ef.png
gs://chromium-docs.appspot.com/ec61c5f15705f5bcf3ca83a155ed647a0538bbe1

[Primiano Tucci (use gerrit), 2017/06/23 08:53:41]

Doesn't really matter. I think those hashes came from using
upload_to_google_storage (part of depot tools). But if you managed to upload
stuff manually with just gsutil works anyways :)

[xunjieli, 2017/06/23 12:51:28]

Acknowledged. Got it. Thank you.

+
 ## How to run the benchmarks
 
 Benchmarks may be run on a local platform/device or remotely on a try job.
@@ -170,7 +176,13 @@ where:
 *   **source:** One of `reported_by_chrome` or `reported_by_os`
 *   **component:** May be a Chrome component, e.g. `skia` or `sqlite`;
     details about a specific component, e.g. `v8:heap`; or a class of memory
-    as seen by the OS, e.g. `system_memory:native_heap` or `gpu_memory`.
+    as seen by the OS, e.g. `system_memory:native_heap` or `gpu_memory`. If
+    reported by chrome, the metrics are gathered by `MemoryDumpProvider`s,
+    probes placed in the specific components' codebase. For example, in
+    "memory:chrome:all_processes:reported_by_chrome:net:effective_size_avg,"
+    the component is "net" which is Chrome's network stack and
+    "reported_by_chrome" means that this metric is gathered via probes in
+    the network stack.
 *   **kind:** The kind of memory being reported. For metrics reported by
     Chrome this usually is `effective_size` (others are `locked_size`
     and `allocated_objects_size`); for metrics by the OS this usually is