Merge pull request #3140 from madeline-underwood/mem2

Memory subsystem with ASCT reviewed

Author: pareenaverma

content/learning-paths/servers-and-cloud-computing/memory-subsystem/_index.md

@@ -3,10 +3,6 @@ title: Characterize the memory subsystem of an Arm Linux system using ASCT
 
 description: Use ASCT to measure cache latency, streaming bandwidth, and coherency latency on Arm Neoverse systems, and compare results across Graviton generations.
 
-draft: true
-cascade:
-    draft: true
-
 minutes_to_complete: 60
 
 who_is_this_for: This is an advanced topic for software developers and performance engineers who want to understand and characterize the CPU-side memory subsystem of Arm Linux systems.
@@ -19,9 +15,9 @@ learning_objectives:
     - Compare results across Arm systems and draw conclusions
 
 prerequisites:
-    - Two or more Arm Linux systems with root or sudo access. The examples use AWS Graviton2 and Graviton4 instances, but other systems are possible.
-    - Arm System Characterization Tool (ASCT) installed on each system.
-    - A good understanding of CPU memory subsystems, including cache hierarchies, cache lines, and DRAM in the memory hierarchy.
+    - Two or more Arm Linux systems with root or sudo access. The examples use AWS Graviton2 and Graviton4 instances, but other systems are possible
+    - Arm System Characterization Tool (ASCT) installed on each system
+    - A good understanding of CPU memory subsystems, including cache hierarchies, cache lines, and DRAM in the memory hierarchy
 
 author: Jason Andrews
 

content/learning-paths/servers-and-cloud-computing/memory-subsystem/cache-hierarchy.md

@@ -1,12 +1,12 @@
 ---
-title: Understand the cache hierarchy
+title: Analyze Arm cache hierarchy and performance characteristics
 weight: 3
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Cache levels and performance clifs
+## Cache levels and performance cliffs
 
 Each memory access is satisfied by the closest level of the hierarchy that contains the requested data. If the data is not found in the private caches, the request falls through to the next cache level and eventually to DRAM. Each level trades capacity for speed: L1 is tiny but fast, L2 is larger but slower, and L3 (or a system-level cache) is the largest on-chip cache but has the highest latency. Understanding this hierarchy for your specific system tells you where performance "cliffs" will occur as your working set grows.
 
@@ -78,9 +78,9 @@ When you access a single byte, the hardware fetches an entire 64-byte cache line
 
 ### Associativity and conflict misses
 
-A 4-way set associative cache can hold 4 lines that map to the same set. If your access pattern happens to map many addresses to the same set, lines get evicted even though the cache isn't full. This is less likely with randomized pointer-chase patterns, but can still occur depending on address distribution and cache indexing but worth understanding.
+A 4-way set associative cache can hold 4 lines that map to the same set. If your access pattern happens to map many addresses to the same set, lines get evicted even though the cache isn't full. Conflict misses are less likely with randomized pointer-chase patterns, but can still occur depending on address distribution and cache indexing, making this concept worth understanding.
 
-### Prefetching
+### Hardware prefetching and cache performance
 
 Modern Arm cores have hardware prefetchers that detect sequential and strided access patterns. They pull data into the cache before the CPU requests it, which can mask latency for predictable patterns. The pointer-chase benchmark in the next section defeats prefetching by design, giving you the true hardware latency rather than the prefetcher-assisted latency.
 
@@ -102,7 +102,7 @@ Compare your `sysfs` findings with the TRM. If the sizes differ, the SoC vendor
 Arm publishes TRMs on the [Arm Developer documentation portal](https://developer.arm.com/documentation/). Search for the specific core name (for example, "Neoverse N1 TRM" or "Neoverse V2 TRM") to find the detailed cache specifications.
 {{% /notice %}}
 
-## What you've accomplished and what's next
+## What you've learned and what's next
 
 In this section you:
 - Reviewed the cache hierarchy for Neoverse N1 (Graviton2) and Neoverse V2 (Graviton4)

content/learning-paths/servers-and-cloud-computing/memory-subsystem/comparative-analysis.md

@@ -1,12 +1,12 @@
 ---
-title: Compare systems and draw conclusions
+title: Compare Arm memory subsystem performance across systems
 weight: 7
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Bringing it all together
+## Complete memory subsystem analysis workflow
 
 You now have a complete set of memory subsystem measurements for each of your test systems. This section shows how to collect all results in one pass, compare systems using ASCT's built-in diff tool, and draw meaningful architectural conclusions.
 
@@ -149,15 +149,15 @@ Collect the key measurements from each system into a comparison table:
 
 The conclusions below are from running ASCT on AWS EC2 instances that are easily available for you to try so you can learn the process and learn how to think about the results. There are many more details that go into CPU microarchitecture and system design that are not covered here, but this is a good way to get an initial understanding of the memory system of an Arm Linux server. 
 
-### Latency
+### Latency analysis across generations
 
 The latency measurements from `latency-sweep` reveal how each generation's cache hierarchy performs. L1 latency is similar across both generations (1.6 ns vs 1.4 ns) because L1 caches are designed for very low latency, so the small difference reflects clock speed rather than cache microarchitecture. L2 latency improves by 27% on Graviton4 (4.0 ns vs 5.4 ns): Neoverse V2 has a 2 MB private L2 compared to Neoverse N1's 1 MB, and despite the larger size, the improved cache pipeline delivers lower latency. LLC latency improves by 24% on Graviton4 (21.8 ns vs 28.8 ns) even though the L3 is only slightly larger (36 MB vs 32 MB), which reflects microarchitectural improvements in the Neoverse V2 cache interconnect. DRAM latency is higher on Graviton4 (114.6 ns vs 95.5 ns, +20%) because DDR5 trades slightly higher access latency for significantly more bandwidth per channel compared to DDR4.
 
-### Loaded latency
+### Loaded latency comparison
 
 The `loaded-latency` results reveal the latency-bandwidth tradeoff. At low load (~3000 NOPs), latency matches the idle DRAM latency from `latency-sweep` (96.7 ns for Graviton2, 115.1 ns for Graviton4), confirming the two benchmarks are consistent. The knee on Graviton2 occurs between 70 and 50 NOPs, where latency nearly doubles from 134 ns to 266 ns before climbing to 344 ns at saturation. On Graviton4 the knee occurs between 30 and 20 NOPs at a much higher bandwidth (~340 GB/s vs ~126 GB/s on Graviton2), and latency plateaus around 190–198 ns at saturation rather than continuing to climb, suggesting the DDR5 memory controllers handle queue saturation more gracefully. Despite Graviton4's higher idle DRAM latency, its latency at saturation is 43% lower than Graviton2's (197 ns vs 344 ns), making it the better choice for workloads that operate near memory bandwidth limits.
 
-### Bandwidth
+### Bandwidth comparison across systems
 
 Single-core bandwidth from `bandwidth-sweep` shows the throughput capacity at each cache level. L1 bandwidth doubles on Graviton4 (321 vs 159 GB/s, +101%), likely reflecting a combination of higher clock speed and microarchitectural throughput improvements in Neoverse V2. L2 bandwidth improves by 29% (95 vs 73 GB/s) due to the wider L2 fill path, and LLC bandwidth more than doubles (80 vs 36 GB/s, +123%), reflecting improvements in the interconnect and shared cache design. Single-core DRAM bandwidth improves by 77% (37 vs 21 GB/s) because Neoverse V2 supports more outstanding memory requests than Neoverse N1 and DDR5 provides more bandwidth per channel than DDR4.
 
@@ -167,11 +167,11 @@ Peak bandwidth from `peak-bandwidth` shows the system-level memory controller ca
 
 The credibility of this type of analysis comes from cross-validation. Check that:
 
-1. Latency steps match cache sizes: the `latency-sweep` boundaries should align with the cache sizes reported by `sysfs` and the TRM.
-2. Bandwidth plateaus match cache sizes: the `bandwidth-sweep` should show transitions at the same data sizes that `latency-sweep` identified.
-3. Peak bandwidth matches documented limits: compare the "All Reads" figure from `peak-bandwidth` against the theoretical peak from `asct system-info`. A well-configured system typically achieves 85-95% of theoretical peak.
-4. Idle loaded latency matches unloaded latency: the lowest-load row from `loaded-latency` should be close to the DRAM latency from `latency-sweep`.
-5. Results are repeatable: run each benchmark at least twice. If results vary by more than 5%, investigate sources of noise (CPU frequency scaling, background processes).
+- Latency steps match cache sizes: the `latency-sweep` boundaries should align with the cache sizes reported by `sysfs` and the TRM.
+- Bandwidth plateaus match cache sizes: the `bandwidth-sweep` should show transitions at the same data sizes that `latency-sweep` identified.
+- Peak bandwidth matches documented limits: compare the "All Reads" figure from `peak-bandwidth` against the theoretical peak from `asct system-info`. A well-configured system typically achieves 85-95% of theoretical peak.
+- Idle loaded latency matches unloaded latency: the lowest-load row from `loaded-latency` should be close to the DRAM latency from `latency-sweep`.
+- Results are repeatable: run each benchmark at least twice. If results vary by more than 5%, investigate sources of noise (CPU frequency scaling, background processes).
 
 {{% notice Tip %}}
 Check if your system allows you to control CPU frequency scaling during benchmarks for more consistent results:
@@ -184,18 +184,18 @@ echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governo
 
 The examples here used AWS Graviton instances, but the methodology works on any Arm Linux machine with a NUMA-enabled kernel. To adapt it:
 
-1. Install ASCT on the target system following the [install guide](/install-guides/asct/).
-2. Run all memory benchmarks: `sudo asct run memory loaded-latency --format=csv --output-dir results_$(hostname)`
-3. Compare with previous systems: `asct diff results_new/ --baseline results_reference/`
-4. Cross-validate: check that latency boundaries, bandwidth plateaus, and peak numbers are consistent with each other and with the hardware documentation.
+- Install ASCT on the target system following the [install guide](/install-guides/asct/).
+- Run all memory benchmarks: `sudo asct run memory loaded-latency --format=csv --output-dir results_$(hostname)`
+- Compare with previous systems: `asct diff results_new/ --baseline results_reference/`
+- Cross-validate: check that latency boundaries, bandwidth plateaus, and peak numbers are consistent with each other and with the hardware documentation.
 
 
-## What you've accomplished
+## What you've learned
 
 In this section you:
 - Identified the topology and cache hierarchy of Arm Linux systems using `sysfs` and `asct system-info`
 - Measured cache and memory latency with the ASCT `latency-sweep` benchmark
 - Measured single-core streaming bandwidth with `bandwidth-sweep`
 - Measured peak system bandwidth with `peak-bandwidth` and the latency-bandwidth tradeoff with `loaded-latency`
 - Compared Graviton2 and Graviton4 to understand how generational improvements in core microarchitecture and memory technology affect real-world performance
-- Developed a portable methodology that works on any Arm Linux system with a single command
+- Developed a portable methodology that works on any Arm Linux system with a single command

content/learning-paths/servers-and-cloud-computing/memory-subsystem/multicore-bandwidth.md

@@ -1,5 +1,5 @@
 ---
-title: Measure multi-core bandwidth and loaded latency
+title: Measure Arm multi-core memory bandwidth and loaded latency with ASCT
 weight: 6
 
 ### FIXED, DO NOT MODIFY
@@ -19,7 +19,7 @@ ASCT includes two benchmarks that characterize multi-core memory behavior:
 
 Both benchmarks depend on `latency-sweep` to determine the optimal data size for targeting DRAM. ASCT runs it automatically as a dependency.
 
-## Peak bandwidth
+## Measure peak system memory bandwidth
 
 The `peak-bandwidth` benchmark makes full use of all cores to measure the maximum system bandwidth. It tests multiple traffic patterns to show how the mix of reads and writes affects peak throughput.
 
@@ -63,7 +63,7 @@ Graviton4 with DDR5 delivers roughly 2.7x the peak all-reads bandwidth of Gravit
 
 Compare the "All Reads" figure with the theoretical peak bandwidth reported by `asct system-info` to see how close each system gets to its maximum. Well-configured systems typically achieve 85-95% of theoretical peak with all-read traffic.
 
-## Loaded latency
+## Measure memory latency under bandwidth load
 
 The `loaded-latency` benchmark measures how memory latency changes as other cores generate increasing bandwidth pressure. It pins a latency-measuring thread on the last core of the first NUMA node and uses the remaining cores to generate background memory traffic. The traffic intensity is controlled by interleaving memory reads with different numbers of no-operation (NOP) instructions. More NOPs means less bandwidth pressure.
 
@@ -142,7 +142,7 @@ On Graviton4, the knee appears between 30 and 20 injected NOPs, where latency ju
 
 Graviton4 has higher idle DRAM latency than Graviton2 (approximately 115 ns vs 96 ns), which is consistent with the `latency-sweep` results. Despite this higher baseline latency, Graviton4's knee occurs at a much higher absolute bandwidth (around 340 GB/s vs 126 GB/s), giving significantly more headroom for bandwidth-sensitive workloads before latency degrades.
 
-## What you've accomplished and what's next
+## What you've learned and what's next
 
 In this section you:
 - Measured peak system bandwidth across multiple traffic patterns with `peak-bandwidth`

content/learning-paths/servers-and-cloud-computing/memory-subsystem/pointer-chase-latency.md

@@ -1,5 +1,5 @@
 ---
-title: Measure cache and memory latency with a pointer chase
+title: Measure Arm cache and memory latency using ASCT pointer chase
 weight: 4
 
 ### FIXED, DO NOT MODIFY
@@ -8,7 +8,7 @@ layout: learningpathall
 
 ## The pointer-chase technique
 
-Cache and memory latency is the single most important metric for characterizing a memory subsystem. The standard technique is a pointer chase, a linked list where each node points to the next, and the CPU must complete each load before it can issue the next one. This creates a chain of dependent loads that defeats both hardware prefetching and out-of-order execution, letting you measure the effective dependent-load latency for this access pattern at each level of the memory hierarchy.
+Cache and memory latency is the single most important metric for characterizing a memory subsystem. The standard technique is a pointer chase, a linked list where each node points to the next, and the CPU must complete each load before it can issue the next one. Making each load depend on the previous one creates a chain of dependent loads that defeats both hardware prefetching and out-of-order execution, letting you measure the effective dependent-load latency for this access pattern at each level of the memory hierarchy.
 
 ## Why pointer chasing works
 
@@ -74,7 +74,7 @@ Latency sweep for Graviton4:
 
 Your actual numbers will differ. The important pattern is the steps in latency as the working set exceeds each cache level.
 
-## Interpret the results
+## Interpret cache latency measurements
 
 Graviton2 uses Neoverse N1 cores with a 64 KB L1D, 1 MB private L2, and a 32 MB shared L3. DRAM is DDR4.
 
@@ -117,7 +117,7 @@ You can view the full list of available benchmarks and their keywords with:
 asct list
 ```
 
-## What you've accomplished and what's next
+## What you've learned and what's next
 
 In this section you:
 - Ran the ASCT `latency-sweep` benchmark to measure pointer-chase latency across the full cache hierarchy and DRAM

content/learning-paths/servers-and-cloud-computing/memory-subsystem/streaming-bandwidth.md

@@ -1,5 +1,5 @@
 ---
-title: Measure single-core streaming bandwidth
+title: Measure Arm single-core memory bandwidth with ASCT
 weight: 5
 
 ### FIXED, DO NOT MODIFY
@@ -52,7 +52,7 @@ Datasize Used Level Bandwidth [GB/s]
 
 Look at the stepping pattern: high bandwidth for L1, a lower plateau for L2, a further drop at the LLC, and then the DRAM floor.
 
-## Interpret the results
+## Interpret bandwidth benchmark results
 
 The `bandwidth-sweep` benchmark reports the bandwidth at the optimal data size for each cache level, using the boundaries that `latency-sweep` identified.
 
@@ -63,7 +63,7 @@ Key differences to look for between Graviton2 and Graviton4:
 - **LLC bandwidth**: Graviton4 more than doubles the LLC bandwidth of Graviton2, reflecting improvements in the interconnect and shared cache design on Neoverse V2.
 - **DRAM bandwidth (single core)**: Graviton4 achieves higher single-core DRAM throughput because Neoverse V2 supports more outstanding memory requests than Neoverse N1, and DDR5 provides more bandwidth per channel than DDR4.
 
-### Bytes per cycle
+### Convert bandwidth to bytes per cycle
 
 To convert GB/s to bytes per cycle, use your core's clock speed:
 
@@ -87,11 +87,11 @@ To run all bandwidth benchmarks at once:
 sudo asct run bandwidth
 ```
 
-## What you've accomplished and what's next
+## What you've learned and what's next
 
 In this section you:
 - Ran the ASCT `bandwidth-sweep` benchmark to measure single-core streaming bandwidth at each cache level
 - Observed bandwidth plateaus corresponding to L1, L2, LLC, and DRAM
 - Learned about additional ASCT benchmarks for peak and cross-NUMA bandwidth
 
-The next section extends this to multi-core bandwidth, showing how shared resources like L3 and DRAM behave under contention.
+The next section extends this to multi-core bandwidth, showing how shared resources like L3 and DRAM behave under contention.

content/learning-paths/servers-and-cloud-computing/memory-subsystem/system-overview.md

@@ -1,11 +1,13 @@
 ---
-title: Identify the system topology and configuration
+title: Identify Arm CPU topology, cache hierarchy, and NUMA configuration
 weight: 2
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
+## Memory subsystem impact on Arm server performance
+
 Memory behavior is one of the primary determinants of compute performance for memory-bound applications. The CPU-side memory subsystem, including caches, interconnects, and DRAM, directly impact performance. Understanding latency, streaming bandwidth, and how caches and cores share resources is essential for diagnosing bottlenecks and tuning software on Arm servers.
 
 ## Identify CPU, cache, and NUMA topology
@@ -241,13 +243,13 @@ On both systems, every core has its own unique L1d, L1i, and L2 index, so those
 
 ### Visualize the topology with hwloc
 
-The `hwloc` package provides a visual representation. Install it using the package manager:
+The `hwloc` package provides a visual representation of the hardware topology, including CPU cores, cache hierarchies, and NUMA nodes. The graphical output makes it easier to understand how cores are organized and which caches they share. Install it using the package manager:
 
 ```bash
 sudo apt-get install -y hwloc
 ```
 
-Generate a graphical representation of the hierarchy:
+Generate a PNG diagram of the complete hardware hierarchy. The `hwloc-ls` command enumerates the system topology and formats it as a tree diagram showing cores, caches, and memory:
 
 ```bash
 hwloc-ls --of png > topology.png
@@ -357,11 +359,11 @@ Below is a summary of each system.
 | L3 (shared) | 32 MB | 36 MB |
 | DRAM type | DDR4 | DDR5 |
 
-## What you've accomplished and what's next
+## What you've learned and what's next
 
 In this section you:
 - Identified the CPU model, core count, and NUMA topology of your test systems
 - Explored the cache hierarchy and cluster layout using `lscpu`, `hwloc`, and `sysfs`
 - Built a reference table of system properties for later comparison
 
-The next section dives deeper into the cache hierarchy and explains what each level does and why the architectural choices matter for performance.
+The next section dives deeper into the cache hierarchy and explains what each level does and why the architectural choices matter for performance.