Rename graviton_perfrunbook to README

So that github will auto-render the README when linked to the folder. Fix links as well. Signed-off-by: Luke Robison <lrbison@amazon.com>
aws · Nov 29, 2023 · a834d80 · a834d80
1 parent a920246
commit a834d80
Show file tree

Hide file tree

Showing 13 changed files with 13 additions and 13 deletions.
diff --git a/README.md b/README.md
@@ -29,7 +29,7 @@ This repository provides technical guidance for users and developers using [Amaz
 * [Spark on Graviton](DataAnalytics.md)
 * [Known issues and workarounds](#known-issues-and-workarounds)
 * [AWS Managed Services available on Graviton](managed_services.md)
-* [Graviton Performance Runbook](perfrunbook/graviton_perfrunbook.md)
+* [Graviton Performance Runbook](perfrunbook/README.md)
 * [Assembly Optimization Guide for Graviton Arm64 Processors](arm64-assembly-optimization.md)
 * [Additional resources](#additional-resources)
 * [How To Resources](howtoresources.md)
@@ -62,7 +62,7 @@ If you are new to Graviton and want to understand how to identify target workloa
 |DDR Encryption	|yes	|yes	|
 
 # Optimizing for Graviton
-Please refer to [optimizing](optimizing.md) for general debugging and profiling information.  For detailed checklists on optimizing and debugging performance on Graviton, see our [performance runbook](perfrunbook/graviton_perfrunbook.md).
+Please refer to [optimizing](optimizing.md) for general debugging and profiling information.  For detailed checklists on optimizing and debugging performance on Graviton, see our [performance runbook](perfrunbook/README.md).
 
 Different architectures and systems have differing capabilities, which means some tools you might be familiar with on one architecture don't have equivalent on AWS Graviton. Documented [Monitoring Tools](Monitoring_Tools_on_Graviton.md) with some of these utilities.
 

diff --git a/perfrunbook/graviton_perfrunbook.md → perfrunbook/README.md b/perfrunbook/graviton_perfrunbook.md → perfrunbook/README.md
diff --git a/perfrunbook/appendix.md b/perfrunbook/appendix.md
@@ -1,6 +1,6 @@
 # Appendix:
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 This Appendix contains additional information for engineers that want to go deeper on a particular topic, such as using different PMU counters to understand how the code is executing on the hardware, discussion on load generators, and additional tools to help with code observability.
 

diff --git a/perfrunbook/configuring_your_loadgen.md b/perfrunbook/configuring_your_loadgen.md
@@ -1,6 +1,6 @@
 # Configuring your load generator
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 The load generator setup is important to understand and verify: it generates the load that is expected.  An unknown load-generation setup can lead to not measuring the expected experiment and getting results that are hard to interpret. Below is a checklist to step through and verify the load generator is working as expected.
 

diff --git a/perfrunbook/configuring_your_sut.md b/perfrunbook/configuring_your_sut.md
@@ -1,6 +1,6 @@
 # Configuring your system-under-test environment
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 This section documents multiple checklists to use to verify your Graviton System-under-test (SUT) is up-to-date and as code-equivalent as possible to the systems and instances you are comparing against.   Please perform these tests on each SUT to vet your experimental setup and eliminate as many potential unknown variables as possible.
 

diff --git a/perfrunbook/debug_code_perf.md b/perfrunbook/debug_code_perf.md
@@ -1,6 +1,6 @@
 # Debugging performance — “What part of the code is slow?”
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 If after checking the system behavior with the sysstat tools the behavior of your code on the CPU is still different, then your next step is to generate code profiles. There are two primary types of profiles 
 

diff --git a/perfrunbook/debug_hw_perf.md b/perfrunbook/debug_hw_perf.md
@@ -1,6 +1,6 @@
 # Debugging performance — “What part of the hardware is slow?”
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 Sometimes, hardware, not code, is the reason for worse than expected performance. This may show up in the on-cpu profiles as every function is slightly slower on Graviton as more CPU time is consumed, but no obvious hot-spot function exists.  If this is the case, then measuring how the hardware performs can offer insight.  To do this requires counting special events in the CPU to understand which component of the CPU is bottlenecking the code from executing as fast as possible.
 

diff --git a/perfrunbook/debug_system_perf.md b/perfrunbook/debug_system_perf.md
@@ -1,6 +1,6 @@
 # Debugging performance — “What part of the system is slow?”
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 When debugging performance, start by measuring high level system behavior to pinpoint what part of the system performs differently when compared with a control instance.  Are the CPUs being saturated or under-saturated?  Is the network or disk behaving differently than expected?  Did a mis-configuration creep in that went undetected when validating the SUT application setup?
 

diff --git a/perfrunbook/defining_your_benchmark.md b/perfrunbook/defining_your_benchmark.md
@@ -1,6 +1,6 @@
 # Defining your benchmark
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 To define a benchmark there are two things to consider, the software running on the System-under-test (SUT) and how to drive load.  We recommend the software running on the SUT should be your production application. There is no better benchmark to predict performance than the actual production code.  If a synthetic proxy must be used to break dependencies of your application on external services such as authentication layers, then that proxy should be derived from the production code as much as possible.  We recommend avoiding synthetic benchmarks not related to the production code.  They are generally poor at predicting performance for another application or helping optimize it as they can over-target specific attributes of a system or exercise different bottlenecks than your application code might.
 

diff --git a/perfrunbook/intro_to_benchmarking.md b/perfrunbook/intro_to_benchmarking.md
@@ -1,6 +1,6 @@
 # Quick introduction to benchmarking
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 When designing an experiment to benchmark Graviton2 against another instance type, it is key to remember the below 2 guiding principles:
 

diff --git a/perfrunbook/optimization_recommendation.md b/perfrunbook/optimization_recommendation.md
@@ -1,6 +1,6 @@
 # Optimizing performance
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 This section describes multiple different optimization suggestions to try on Graviton2 instances to attain higher performance for your service.  Each sub-section defines some optimization recommendations that can help improve performance if you see a particular signature after measuring the performance using the previous checklists.
 

diff --git a/perfrunbook/references.md b/perfrunbook/references.md
@@ -1,6 +1,6 @@
 # References
 
-[Graviton Performance Runbook toplevel](./graviton_perfrunbook.md)
+[Graviton Performance Runbook toplevel](./README.md)
 
 Experimental design:
 

diff --git a/transition-guide.md b/transition-guide.md
@@ -94,7 +94,7 @@ One of the major differences between AWS Graviton instances and other Amazon EC2
 
 During the transition to Graviton, if you are using Amazon EC2 Auto Scaling, you may be able to increase the threshold values for the CloudWatch alarms that invoke the scaling process. This may reduce the number of EC2 instances now needed to serve a given level of demand.
 
-Important: This repository has sections dedicated to [Optimization](optimizing.md) and a [Performance Runbook](perfrunbook/graviton_perfrunbook.md) for you to follow during this stage.
+Important: This repository has sections dedicated to [Optimization](optimizing.md) and a [Performance Runbook](perfrunbook/README.md) for you to follow during this stage.
 
 If after reading the documentation in this repository and following the recommendations you do not observe expected performance then please reach out to your AWS account team, or send email to [ec2-arm-dev-feedback@amazon.com](mailto:ec2-arm-dev-feedback@amazon.com) with details so we can assist you with your performance observations.