Fix links to memory-infra README and add a note about reading traces.

docs/memory-infra/memory_benchmarks.md

 # Memory Benchmarks
 
 This document describes benchmarks available to track Chrome's and
 WebView's memory usage, where they live, what they measure, how to run them,
 and on how to diagnose regressions.
 
 [TOC]
 
 ## Glossary
 
@@ skipping 77 matching lines @@
     see internal bots.
 *   **Subtest (1):** The name of a *[metric](#Understanding-memory-metrics)*.
 *   **Subtest (2):** The name of a *story group*; these have the form
     `{interaction}_{category}` for system health stories.
 *   **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.
+(More information about reading trace files [here][memory-infra])
+
+[memory-infra]: /docs/memory-infra/README.md
 
 ![Chrome Performance Dashboard Alert](https://storage.googleapis.com/chromium-docs.appspot.com/perfdashboard_alert.png)
 
 ## How to run the benchmarks
 
 Benchmarks may be run on a local platform/device or remotely on a try job.
 
 ### How to run locally
 
 After building, e.g. `ChromePublic.apk`, you can run a specific system health
@@ skipping 17 matching lines @@
      to get individual [trace files][memory-infra] in addition to the
      `results.html` file.
 *   `--reset-results` - clear results from any previous benchmark runs in the
     `results.html` file.
 *   `--results-label [label]` - give meaningful names to your benchmark runs,
     this way it is easier to compare them.
 
 For WebView make sure to [replace the system WebView][webview_install]
 on your device and use `--browser android-webview`.
 
+[memory-infra]: /docs/memory-infra/README.md
 [webview_install]: https://www.chromium.org/developers/how-tos/build-instructions-android-webview
 
 ### How to run a try job
 
 Given a patch on a chromium checkout, try jobs provide a convenient way to
 evaluate its memory implications on devices or platforms which
 may not be immediately available to developers.
 
 To start a try job [upload a CL][contributing] and run the command, e.g.:
 
@@ skipping 37 matching lines @@
     "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
     `proportional_resident_size` (others are `peak_resident_size` and
     `private_dirty_size`).
 
-[memory-infra]: /memory-infra/README.md
+[memory-infra]: /docs/memory-infra/README.md
 
 ## Appendix
 
 There are a few other benchmarks maintained by the memory-infra team.
 These also use the same set of metrics as system health, but have differences
 on the kind of stories that they run.
 
 ### memory.top_10_mobile
 
 The [memory.top_10_mobile][memory_py] benchmark is in the process of being deprecated
@@ skipping 38 matching lines @@
 
     Story groups are either `on_chrome` or `on_webview`, indicating the browser
     in foreground at the moment when the memory measurement was made.
 
 *   [memory.long_running_dual_browser_test][memory_extra_py] - same as above,
     but the test is run for 60 iterations keeping both browsers alive for the
     whole duration of the test and without forcing garbage collection. Intended
     as a last-resort net to catch memory leaks not apparent on shorter tests.
 
 [memory_extra_py]: https://cs.chromium.org/chromium/src/tools/perf/contrib/memory_extras/memory_extras.py