Update titles and section headings for clarity in memory subsystem documentation

Author: madeline-underwood

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.
 
@@ -80,7 +80,7 @@ When you access a single byte, the hardware fetches an entire 64-byte cache line
 
 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.
 

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.
 

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.
 

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
@@ -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.
 

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:
 

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

@@ -1,5 +1,5 @@
 ---
-title: Identify the system topology and configuration
+title: Identify Arm CPU topology, cache hierarchy, and NUMA configuration
 weight: 2
 
 ### FIXED, DO NOT MODIFY