reviewing memory subsystem with ASCT

Author: jasonrandrews

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

@@ -67,7 +67,7 @@ On Graviton4 the output is:
 
 Pay attention to:
 - **Associativity**: higher associativity reduces conflict misses but can increase access latency.
-- **Line size**: almost universally 64 bytes on Arm, which matters for stride-based benchmarks.
+- **Line size**: almost universally 64 bytes on modern Arm server cores, which matters for stride-based benchmarks.
 - **Shared CPU list**: tells you exactly which cores share each cache level.
 
 ## Key concepts to carry forward
@@ -80,7 +80,7 @@ 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 rare in practice for pointer-chase benchmarks 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. This is less likely with randomized pointer-chase patterns, but can still occur depending on address distribution and cache indexing but worth understanding.
 
 ### Prefetching
 

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

@@ -151,7 +151,7 @@ Collect the key measurements from each system into a comparison table:
 
 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). L1 caches are designed for near-single-cycle access, so the small difference reflects clock speed rather than cache microarchitecture.
+- **L1 latency** is similar across both generations (1.6 ns vs 1.4 ns). L1 caches are designed for very low latency (typically a few cycles), 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 N1's 1 MB. Despite the larger size, V2's improved cache pipeline delivers lower latency.
 - **LLC latency** improves by 24% on Graviton4 (21.8 ns vs 28.8 ns), despite the L3 being only slightly larger (36 MB vs 32 MB). This reflects microarchitectural improvements in the V2 cache interconnect.
 - **DRAM latency** is higher on Graviton4 (114.6 ns vs 95.5 ns, +20%). DDR5 trades slightly higher access latency for significantly more bandwidth per channel compared to DDR4.

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

@@ -57,7 +57,7 @@ Peak memory bandwidth
 Several patterns emerge from the traffic type comparison:
 
 - **All Reads** gives the highest throughput because reads are simpler for the memory controller, with no write-back or write-allocate overhead.
-- **Read-write mixes** reduce throughput progressively as the write ratio increases. Writes require the controller to alternate between read and write bus turnarounds, and each write involves a cache line allocation and potential eviction.
+- **Read-write mixes** reduce throughput progressively as the write ratio increases. Writes require the controller to alternate between read and write bus turnarounds, and in write-allocate caches, writes typically trigger a read-for-ownership and eventual eviction, increasing traffic. Non-temporal writes can avoid this overhead.
 
 Graviton4 with DDR5 delivers roughly 2.7x the peak all-reads bandwidth of Graviton2 with DDR4 (465.5 vs 169.6 GB/s). The Graviton4 output also includes a non-temporal traffic pattern (2:1 Rd-Wr Non-Temporal), which bypasses the cache on writes and can be more efficient for pure streaming workloads.
 

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

@@ -14,7 +14,7 @@ Cache and memory latency is the single most important metric for characterizing
 
 Hardware prefetchers detect sequential and strided access patterns and fetch data ahead of the CPU. If you write a loop that reads an array sequentially, the prefetcher hides much of the latency. A pointer chase randomizes the order of accesses so the prefetcher can't predict the next address.
 
-Out-of-order execution is the other concern. Modern Arm cores can issue multiple independent loads in parallel, overlapping their latencies. By making each load depend on the result of the previous load (the pointer), you force the CPU to serialize them. The measured time per access then reflects the true round-trip latency to wherever the data resides.
+Out-of-order execution is the other concern. Modern Arm cores can issue multiple independent loads in parallel, overlapping their latencies. By making each load depend on the result of the previous load (the pointer), you limit memory-level parallelism and prevent the core from overlapping multiple memory accesses. The measured time per access then reflects the true round-trip latency to wherever the data resides.
 
 ## Measure cache and memory latency with ASCT
 

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

@@ -69,7 +69,7 @@ To convert GB/s to bytes per cycle, use your core's clock speed:
 
 $$\text{Bytes/cycle} = \frac{\text{GB/s} \times 10^9}{\text{Clock (Hz)}}$$
 
-This normalization lets you compare microarchitectural efficiency independent of clock speed. The benchmark measures combined load and store throughput, so the effective bytes-per-cycle will exceed the 32 bytes/cycle read-only peak of the two 128-bit load ports. V2's dedicated store port gives it an additional advantage in this measurement.
+This normalization lets you compare microarchitectural efficiency independent of clock speed. The benchmark measures combined load and store throughput, so the combined load and store throughput can exceed the read-only peak of the load ports alone of the two 128-bit load ports. V2's dedicated store port gives it an additional advantage in this measurement.
 
 ## Additional ASCT bandwidth benchmarks
 

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

@@ -52,7 +52,7 @@ Record the kernel version and operating system. Run the following command on you
 uname -a && cat /etc/os-release
 ```
 
-Both systems have the same software:
+Both systems have the same software (example output; kernel version may differ depending on distribution updates):
 
 ```output
 Linux graviton2-c6g 6.17.0-1007-aws #7~24.04.1-Ubuntu SMP Thu Jan 22 20:37:30 UTC 2026 aarch64 aarch64 aarch64 GNU/Linux
@@ -153,9 +153,9 @@ Both systems have 128 GB RAM with similar output:
 Mem:           123Gi       1.6Gi       121Gi       1.2Mi       1.2Gi       121Gi
 ```
 
-Graviton2 instances use DDR4 memory. Graviton4 instances use DDR5 memory, which provides higher bandwidth per channel and lower access latency.
+Graviton2 instances use DDR4 memory. Graviton4 instances use DDR5 memory, which provides higher bandwidth per channel than DDR4, but typically has slightly higher access latency in nanoseconds.
 
-Both systems have a single NUMA node, meaning all cores have uniform access to all memory. On multi-socket Arm servers with multiple NUMA nodes, memory access latency depends on which node the data resides on. The ASCT `idle-latency` and `cross-numa-bandwidth` benchmarks are designed for those systems but won't produce interesting results on single-node configurations like these.
+Both systems have a single NUMA node, meaning all cores have uniform access to all memory. On multi-socket Arm servers with multiple NUMA nodes, memory access latency depends on which node the data resides on. The ASCT `idle-latency` and `cross-numa-bandwidth` benchmarks are designed for those systems but will show minimal variation on single-node systems like these on single-node configurations like these.
 
 ## Explore the core and cluster topology
 
@@ -237,7 +237,7 @@ CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
  63    0      0   63 63:63:63:0       yes
 ```
 
-On both systems, every core has its own unique L1d, L1i, and L2 index, so those caches are private. The L3 index is `0` for all cores, confirming that all 64 cores share a single L3 cache on each system.
+On both systems, every core has its own unique L1d, L1i, and L2 index, so those caches are private. The L3 index is `0` for all cores, confirming that the system exposes a single shared LLC across all cores, although it may be physically distributed across the interconnect on each system.
 
 ### Visualize the topology with hwloc