Updates

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/false-sharing-arm-spe/_index.md

@@ -1,9 +1,6 @@
 ---
 title: Analyze cache behavior with Perf C2C on Arm
 
-
-
-
 minutes_to_complete: 15
 
 who_is_this_for: This topic is for performance-oriented developers working on Arm-based cloud or server systems who want to optimize memory access patterns and investigate cache inefficiencies using Perf C2C and Arm SPE.

content/learning-paths/servers-and-cloud-computing/false-sharing-arm-spe/how-to-1.md

@@ -1,29 +1,38 @@
 ---
-title: Introduction to Arm SPE and false sharing
+title: Arm Statistical Profiling Extension and false sharing
 weight: 2
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
-## Introduction to the Arm Statistical Profiling Extension (SPE)
 
-Traditional Linux performance profiling tools often rely on retired instruction counts, which lack visibility into memory addresses, cache latencies, and micro-operation behavior. Moreover, the “skid” phenomenon where events are falsely attributed to later instructions can mislead developers. 
+## What is the Arm Statistical Profiling Extension (SPE), and what does it do?
 
-SPE integrates sampling directly into the CPU pipeline, triggering on individual micro-operations rather than retired instructions, thereby eliminating skid and blind spots. Each SPE sample record includes relevant metadata, such as data addresses, per-µop pipeline latency, triggered PMU event masks, and the memory hierarchy source, enabling fine-grained and precise cache analysis. 
+{{% notice Learning goal%}}
+In this section, you will learn how the Arm Statistical Profiling Extension (SPE) gives you deeper visibility into how your applications interact with the CPU. It covers how to detect and fix false sharing, which is a hidden performance problem in multithreaded code, by using cache line alignment in C++ and tools like Perf C2C.
+{{% /notice %}}
+
+Arm’s Statistical Profiling Extension (SPE) gives you a powerful way to understand what’s really happening inside your applications at the microarchitecture level. Introduced in Armv8.2, SPE captures a statistical view of how instructions move through the CPU, which allows you to dig into issues like memory access latency, cache misses, and pipeline behavior.
+
+Most Linux profiling tools focus on retired instruction counts, which means they miss key details like memory addresses, cache latency, and micro-operation behavior. This can lead to misleading results — especially due to a phenomenon called “skid,” where events are falsely attributed to later instructions.
+
+SPE integrates sampling directly into the CPU pipeline, triggering on individual micro-operations instead of retired instructions. This approach eliminates skid and blind spots. Each SPE sample record includes relevant metadata, such as data addresses, per-µop pipeline latency, triggered PMU event masks, and the memory hierarchy source, enabling fine-grained, precise cache analysis. 
 
 SPE helps developers optimize user-space applications by showing where cache latency or memory access delays are happening. Importantly, cache statistics are enabled with the Linux Perf cache-to-cache (C2C) utility.
 
-To learn more, check out the [Arm SPE white paper](https://developer.arm.com/documentation/109429/latest/) for more information. 
+For more information, see the [*Arm Statistical Profiling Extension: Performance Analysis Methodology White Paper*](https://developer.arm.com/documentation/109429/latest/). 
 
 In this Learning Path, you will use SPE and Perf C2C to diagnose a cache issue for an application running on a Neoverse server.
 
 ## What is false sharing and why should I care about it?
 
 In large-scale, multithreaded applications, false sharing can degrade performance by introducing hundreds of unnecessary cache line invalidations per second - often with no visible red flags in the source code.
 
-Even when two threads touch entirely separate variables, modern processors move data in fixed-size cache lines (nominally 64-bytes). If those distinct variables happen to occupy bytes within the same line, every time one thread writes its variable the core’s cache must gain exclusive ownership of the whole line, forcing the other core’s copy to be invalidated. 
+Even when two threads touch entirely separate variables, modern processors move data in fixed-size cache lines, which is typically 64 bytes. If those distinct variables happen to occupy bytes within the same line, every time one thread writes its variable the core’s cache must gain exclusive ownership of the whole line, forcing the other core’s copy to be invalidated. 
 
-The second thread, still working on its own variable, then triggers a coherence miss to fetch the line back, and the ping-pong pattern repeats. See the illustration below, taken from the Arm SPE white paper, for a visual explanation.
+The second thread, still working on its own variable, then triggers a coherence miss to fetch the line back, and the ping-pong pattern repeats. 
+
+The diagram below, taken from the Arm SPE white paper, provides a visual representation of two threads on separate cores alternately gaining exclusive access to the same cache line.
 
 ![false_sharing_diagram alt-text#center](./false_sharing_diagram.png "Two threads on separate cores alternately gain exclusive access to the same cache line.")
 
@@ -77,9 +86,9 @@ int main() {
 }
 ```
 
-The example output below shows the variables e, f, g and h occur at least 64 bytes apart in the byte-addressable architecture. Whereas variables a, b, c, and d occur 8 bytes apart, occupying the same cache line. 
+The output below shows that the variables e, f, g and h occur at least 64 bytes apart in the byte-addressable architecture. Whereas variables a, b, c, and d occur 8 bytes apart, occupying the same cache line. 
 
-Although this is a contrived example, in a production workload there might be several layers of indirection that unintentionally result in false sharing. For these complex cases, to understand the root cause you will use Perf C2C.
+Although this is a contrived example, in a production workload there might be several layers of indirection that unintentionally result in false sharing. For these complex cases, to understand the root cause, you can use Perf C2C.
 
 ```output
 Without Alignment can occupy same cache line
@@ -101,7 +110,8 @@ Address of AlignedType h - 0xffffeb6c6080
 
 ## Summary
 
-In this section, you learned what Arm SPE is and why it’s a game-changer for performance profiling. You also saw how a subtle issue like false sharing can slow down multithreaded code — and how to avoid it using alignment in C++.
+In this section, you explored what Arm SPE is and why it offers a deeper, more accurate view of application performance. You also examined how a subtle issue like false sharing can impact multithreaded code, and how to mitigate it using data alignment techniques in C++.
+
+Next, you'll set up your environment and use Perf C2C to capture and analyze real cache behavior on an Arm Neoverse system.
 
-Next up: you’ll set up your environment and get ready to run Perf C2C on a real application. 
 

content/learning-paths/servers-and-cloud-computing/false-sharing-arm-spe/how-to-2.md

@@ -1,20 +1,23 @@
 ---
-title: Configure your environment for Arm SPE profiling
+title: Environment setup for Arm SPE profiling
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
-
 ## Select a system with SPE support
 
-SPE requires both hardware and operating system support. Many cloud instances running Linux do not enable SPE-based profiling.
+{{% notice Learning goal%}}
+Before you can start profiling cache behavior with Arm SPE and Perf C2C, your system needs to meet a few requirements. In this section, you’ll learn how to check whether your hardware and kernel support Arm SPE, install the necessary tools, and validate that Linux Perf can access the right performance monitoring events. By the end, your environment will be ready to record and analyze memory access patterns using Perf C2C on an Arm Neoverse system.
+{{% /notice %}}
+
+SPE requires support from both your hardware and the operating system. Many cloud instances running Linux do not enable SPE-based profiling.
 
 You need to identify a system that supports SPE using the information below. 
 
 If you are looking for an AWS system, you can use a `c6g.metal` instance running Amazon Linux 2023 (AL2023). 
 
-Check the underlying Neoverse processor and operating system kernel version with the following commands. 
+Check the underlying Neoverse processor and operating system kernel version with the following commands: 
 
 ```bash
 lscpu | grep -i "model name"
@@ -43,15 +46,15 @@ Run the following command to confirm if the SPE kernel module is loaded:
 sudo modprobe arm_spe_pmu
 ```
 
-If the module is not loaded (blank output), SPE might still be available.
+If the module is not loaded (and there is blank output), SPE might still be available.
 
 Run this command to check if SPE is included in the kernel:
 
 ```bash
 ls /sys/bus/event_source/devices/ | grep arm_spe
 ```
 
-If SPE is available, the output is:
+If SPE is available, the output you will see is:
 
 ```output
 arm_spe_0
@@ -63,7 +66,7 @@ If the output is blank then SPE is not available.
 
 You can install and run a Python script named Sysreport to summarize your system's performance profiling capabilities.
 
-See [Get ready for performance analysis with Sysreport](https://learn.arm.com/learning-paths/servers-and-cloud-computing/sysreport/) to learn how to install and run it.
+See the Learning Path [Get ready for performance analysis with Sysreport](https://learn.arm.com/learning-paths/servers-and-cloud-computing/sysreport/) to learn how to install and run it.
 
 Look at the Sysreport output and confirm SPE is available by checking the `perf sampling` field. 
 
@@ -99,21 +102,21 @@ List of pre-defined events (to be used in -e or -M):
   arm_spe_0//                                        [Kernel PMU event]
 ```
 
-Assign capabilities to Perf by running:
+Assign capabilities to `perf` by running:
 
 ```bash
 sudo setcap cap_perfmon,cap_sys_ptrace,cap_sys_admin+ep $(which perf)
 ```
 
-If `arm_spe` is not available because of your system configuration or if you don't have PMU permission, the `perf c2c` command fails. 
+If `arm_spe` isn’t available due to your system configuration or limited PMU access, the `perf c2c` command will fail.
 
 To confirm Perf can access SPE, run:
 
 ```bash
 perf c2c record
 ```
 
-The output showing the failure is:
+If SPE access is blocked, you’ll see output like this:
 
 ```output
 failed: memory events not supported
@@ -122,9 +125,11 @@ failed: memory events not supported
 {{% notice Note %}}
 If you are unable to use SPE it might be a restriction based on your cloud instance size or operating system.
 
-Generally, access to a full server (also known as metal instances) with a relatively new kernel is needed for Arm SPE support. 
+Generally, access to a full server (also known as metal instances) with a relatively new kernel is required for Arm SPE support. 
 
 For more information about enabling SPE, see the [perf-arm-spe manual page](https://man7.org/linux/man-pages/man1/perf-arm-spe.1.html)
 {{% /notice %}}
 
-Continue to learn how to use Perf C2C on an example application.
+## Summary
+
+You've confirmed that your system supports Arm SPE, installed the necessary tools, and verified that perf can access SPE events. You're now ready to start collecting detailed performance data using perf c2c. In the next section, you’ll run a real application and use Perf C2C to capture cache sharing behavior and uncover memory performance issues.

content/learning-paths/servers-and-cloud-computing/false-sharing-arm-spe/how-to-3.md

@@ -8,6 +8,10 @@ layout: learningpathall
 
 ## Example code
 
+{{% notice Learning Goal%}}
+The example code in this section demonstrates how false sharing affects performance by comparing two multithreaded programs — one with cache-aligned data structures and one without. You’ll compile and run both versions, observe the runtime difference, and learn how memory layout affects cache behavior. This sets the stage for analyzing performance with Perf C2C in the next section.
+{{% /notice %}}
+
 Use a text editor to copy and paste the C example code below into a file named `false_sharing_example.c`
 
 The code is adapted from [Joe Mario](https://github.com/joemario/perf-c2c-usage-files) and is discussed thoroughly in the Arm Statistical Profiling Extension Whitepaper.
@@ -285,7 +289,7 @@ int main ( int argc, char *argv[] )
 
 ### Code explanation
 
-The key data structure that occupies the cache is `struct Buf`. With a 64-byte cache line size, each line can hold 8, 8-byte `long` integers. 
+The key data structure that occupies the cache is `struct _buf`. With a 64-byte cache line size, each line can hold 8, 8-byte `long` integers. 
 
 If you do not pass in the `NO_FALSE_SHARING` macro during compilation the `Buf` data structure will contain the elements below. Each structure neatly occupies the entire 64-byte cache line. 
 
@@ -306,7 +310,7 @@ typedef struct _buf {
 
 Alternatively if you pass in the `NO_FALSE_SHARING` macro during compilation, the `Buf` structure has a different shape. 
 
-The 40 bytes of padding pushes the reader variables onto a different cache line. However, notice that this is with the tradeoff the new `Buf` structures occupies multiple cache lines (12 long integers). Therefore it leaves unused cache space of 25% per `Buf` structure.
+The 40 bytes of padding pushes the reader variables onto a different cache line. However, notice that this is with the tradeoff the new `Buf` structures occupies multiple cache lines (12 long integers). Therefore it leaves unused cache space of 25% per `Buf` structure. This trade-off uses more memory but eliminates false sharing, improving performance by reducing cache line contention.
 
 ```output
 typedef struct _buf {
@@ -345,5 +349,6 @@ user    0m8.869s
 sys     0m0.000s
 ```
 
-Continue to the next section to learn how to use Perf C2C to analyze the example code.
+## Summary
+In this section, you ran a hands-on C example to see how false sharing can significantly degrade performance in multithreaded applications. By comparing two versions of the same program, one with aligned memory access and one without, you saw how something as subtle as cache line layout can result in a 2x difference in runtime. This practical example sets the foundation for using Perf C2C to capture and analyze real cache line sharing behavior in the next section.
 

content/learning-paths/servers-and-cloud-computing/false-sharing-arm-spe/how-to-4.md

@@ -6,9 +6,13 @@ weight: 5
 layout: learningpathall
 ---
 
-## Measuring Performance
+## Compare Performance with perf stat
 
-A straight forward method to observe the performance characteristics of both binaries would be to use the `perf stat` command. 
+{{% notice Learning goal %}}
+In this section, you’ll learn how to use Linux Perf tools and Arm SPE to identify performance bottlenecks in multithreaded applications. You’ll compare aligned and unaligned workloads, detect cache-related slowdowns like false sharing, and trace memory contention down to the source code using Perf C2C.
+{{% /notice %}}
+
+A straightforward method to observe the performance characteristics of both binaries would be to use the `perf stat` command. 
 
 For example, run the false sharing version using:
 
@@ -66,13 +70,13 @@ The output is similar to:
 
 Comparing the results you can see the run time is significantly different (13.01 s vs. 6.49 s). 
 
-Additionally, the instructions per cycle (IPC) is notably different, (0.74 vs. 1.70) and looks to be commensurate to run time. 
+The instructions per cycle (IPC) are also notably different, (0.74 vs. 1.70) and look to be commensurate to run time. 
 
-## Understanding the root cause
+## Pinpoint pipeline bottlenecks with top-down analysis
 
 There are many root causes of variations in IPC. 
 
-To identify an area to focus on we will start off using the [top-down methodology](https://developer.arm.com/documentation/109542/0100/Arm-Topdown-methodology). Install the python script using the [install guide](https://learn.arm.com/install-guides/topdown-tool/).
+To identify where the bottleneck occurs, we’ll start by using the [Arm Topdown methodology](https://developer.arm.com/documentation/109542/0100/Arm-Topdown-methodology). Install the python script using the [Telemetry Solution Install Guide](https://learn.arm.com/install-guides/topdown-tool/).
 
 Run the following command to observe the ratio of frontend to backend stall cycles. These indicate which section of the CPU pipeline is waiting on resources and causing slower performance. 
 
@@ -92,7 +96,7 @@ Backend Stalled Cycles. 75.24% cycles
 
 The output shows there are disproportionately more backend stall cycles. This indicates the CPU is waiting for data. You could follow the top-down methodology further looking at the stage 2 microarchitecture analysis, but for sake of brevity you can jump to recording events with SPE.
 
-## Skid when using Perf Record
+## Skid: When perf record misleads
 
 The naive approach would be to record the events using the `perf record` subcommand. Running the following commands can be used to demonstrate skid, inaccuracy or "slippage" in the instruction location recorded by the Performance Monitoring Unit (PMU) when a performance event is sampled. 
 
@@ -155,4 +159,8 @@ Looking at the corresponding source code, we observe the following.
 
 The output from SPE-based profiling with Perf C2C shows that attempting to access and increment the `lock0` and `reader1` variable, is causing the bottleneck. 
 
-The insight generated from Perf C2C indicates to reorganize the layout of the data structure.
+The insight generated from Perf C2C indicates to reorganize the layout of the data structure.
+
+## Summary
+
+In this section, you used multiple tools to analyze and diagnose a real performance issue caused by false sharing. You compared performance between aligned and unaligned code using perf stat, investigated backend stalls with topdown-tool, and saw how standard perf record can mislead due to instruction skid. Finally, you used Perf C2C with Arm SPE to pinpoint the exact variables and code lines causing contention, giving you actionable insight into how to reorganize your data layout for better performance.