From a834d804f363ec7cb4fd5b716bf2310cfc3955c8 Mon Sep 17 00:00:00 2001 From: Luke Robison Date: Fri, 24 Nov 2023 21:48:32 +0000 Subject: [PATCH] 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 --- README.md | 4 ++-- perfrunbook/{graviton_perfrunbook.md => README.md} | 0 perfrunbook/appendix.md | 2 +- perfrunbook/configuring_your_loadgen.md | 2 +- perfrunbook/configuring_your_sut.md | 2 +- perfrunbook/debug_code_perf.md | 2 +- perfrunbook/debug_hw_perf.md | 2 +- perfrunbook/debug_system_perf.md | 2 +- perfrunbook/defining_your_benchmark.md | 2 +- perfrunbook/intro_to_benchmarking.md | 2 +- perfrunbook/optimization_recommendation.md | 2 +- perfrunbook/references.md | 2 +- transition-guide.md | 2 +- 13 files changed, 13 insertions(+), 13 deletions(-) rename perfrunbook/{graviton_perfrunbook.md => README.md} (100%) diff --git a/README.md b/README.md index 250c9fa2..823e090f 100644 --- 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 b/perfrunbook/README.md similarity index 100% rename from perfrunbook/graviton_perfrunbook.md rename to perfrunbook/README.md diff --git a/perfrunbook/appendix.md b/perfrunbook/appendix.md index 796eedfa..1d79115f 100644 --- 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 index 1d7cf521..cd33c714 100644 --- 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 index 1e7cb7e0..fd89db47 100644 --- 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 index fc301604..a6b47b31 100644 --- 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 index 8c70e419..0d193ecf 100644 --- 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 index d375ec95..0a784ac8 100644 --- 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 index af358eeb..92bb20a5 100644 --- 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 index 6e012a1f..87b51893 100644 --- 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 index c3ed31be..cc43cd37 100644 --- 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 index c8fc319e..b40b0961 100644 --- 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 index 4bac9df4..a906e061 100644 --- 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.