Merge pull request #2398 from jasonrandrews/review

Review top-down methodology Learning Path

Author: jasonrandrews

content/learning-paths/cross-platform/topdown-compare/1-top-down.md

@@ -14,17 +14,20 @@ Both Intel x86 and Arm Neoverse CPUs provide sophisticated Performance Monitorin
 
 While the specific counter names and formulas differ between architectures, both Intel x86 and Arm Neoverse have converged on top-down performance analysis methodologies that categorize performance bottlenecks into four key areas:
 
-**Retiring** represents pipeline slots that successfully complete useful work, while **Bad Speculation** accounts for slots wasted on mispredicted branches. Additionally, **Frontend Bound** identifies slots stalled due to instruction fetch and decode limitations, and **Backend Bound** covers slots stalled by execution resource constraints.
+- Retiring
+- Bad Speculation
+- Frontend Bound
+- Backend Bound
 
-This Learning Path provides a comparison of how x86 processors implement four-level hierarchical top-down analysis compared to Arm Neoverse's two-stage methodology, highlighting the similarities in approach while explaining the architectural differences in PMU counter events and formulas.
+This Learning Path provides a comparison of how x86 processors implement multi-level hierarchical top-down analysis compared to Arm Neoverse's methodology, highlighting the similarities in approach while explaining the architectural differences in PMU counter events and formulas.
 
 ## Introduction to top-down performance analysis
 
-The top-down methodology makes performance analysis easier by shifting focus from individual PMU counters to pipeline slot utilization. Instead of trying to interpret dozens of seemingly unrelated metrics, you can systematically identify bottlenecks by attributing each CPU pipeline slot to one of four categories.
+The top-down methodology makes performance analysis easier by shifting focus from individual PMU counters to pipeline slot utilization. Instead of trying to interpret dozens of seemingly unrelated metrics, you can systematically identify bottlenecks by attributing each CPU pipeline slot to one of the four categories.
 
 **Retiring** represents pipeline slots that successfully complete useful work, while **Bad Speculation** accounts for slots wasted on mispredicted branches and pipeline flushes. **Frontend Bound** identifies slots stalled due to instruction fetch and decode limitations, whereas **Backend Bound** covers slots stalled by execution resource constraints such as cache misses or arithmetic unit availability.
 
-The methodology uses a hierarchical approach that allows you to drill down only into the dominant bottleneck category, and avoid the complexity of analyzing all possible performance issues at the same time. 
+The methodology allows you to drill down only into the dominant bottleneck category, avoiding the complexity of analyzing all possible performance issues at the same time. 
 
 The next sections compare the Intel x86 methodology with the Arm top-down methodology. 
 

content/learning-paths/cross-platform/topdown-compare/1a-intel.md

@@ -1,5 +1,5 @@
 ---
-title: "Implement Intel x86 4-level hierarchical top-down analysis"
+title: "Understand Intel x86 multi-level hierarchical top-down analysis"
 weight: 4
 
 ### FIXED, DO NOT MODIFY
@@ -8,9 +8,9 @@ layout: learningpathall
 
 ## Configure slot-based accounting with Intel x86 PMU counters
 
-Intel uses a slot-based accounting model where each CPU cycle provides multiple issue slots. A slot is a hardware resource needed to process micro-operations (uops). More slots means more work can be done per cycle. The number of slots depends on the microarchitecture design but current Intel processor designs typically have four issue slots per cycle.
+Intel uses a slot-based accounting model where each CPU cycle provides multiple issue slots. A slot is a hardware resource needed to process micro-operations (uops). More slots means more work can be done per cycle. The number of slots depends on the microarchitecture design, but current Intel processor designs typically have four issue slots per cycle.
 
-Intel's methodology uses a multi-level hierarchy that extends to 4 levels of detail. Each level provides progressively more granular analysis, allowing you to drill down from high-level categories to specific microarchitecture events.
+Intel's methodology uses a multi-level hierarchy that typically extends to 3-4 levels of detail. Each level provides progressively more granular analysis, allowing you to drill down from high-level categories to specific microarchitecture events.
 
 ## Level 1: Identify top-level performance categories
 
@@ -27,18 +27,20 @@ Where `SLOTS = 4 * CPU_CLK_UNHALTED.THREAD` on most Intel cores.
 
 Once you've identified the dominant Level 1 category, Level 2 drills into each area to identify broader causes. This level distinguishes between frontend latency and bandwidth limits, or between memory and core execution stalls in the backend.
 
-- Frontend Bound covers frontend latency in comparison with frontend bandwidth
-- Backend Bound covers memory bound in comparison with core bound
-- Bad Speculation covers branch mispredicts in comparison with machine clears
-- Retiring covers base in comparison with microcode sequencer
+- Frontend Bound covers frontend latency compared with frontend bandwidth
+- Backend Bound covers memory bound compared with core bound
+- Bad Speculation covers branch mispredicts compared with machine clears
+- Retiring covers base compared with microcode sequencer
 
 ## Level 3: Target specific microarchitecture bottlenecks
 
-After identifying broader cause categories in Level 2, Level 3 provides fine-grained attribution that pinpoints specific bottlenecks like DRAM latency, cache misses, or port contention. This precision makes it possible to identify the exact root cause and apply targeted optimizations. Memory Bound expands into detailed cache hierarchy analysis including L1 Bound, L2 Bound, L3 Bound, DRAM Bound, and Store Bound categories, while Core Bound breaks down into execution unit constraints such as Divider and Ports Utilization, along with many other specific microarchitecture-level categories that enable precise performance tuning.
+After identifying broader cause categories in Level 2, Level 3 provides fine-grained attribution that pinpoints specific bottlenecks like DRAM latency, cache misses, or port contention. This precision makes it possible to identify the exact root cause and apply targeted optimizations. 
+
+Memory Bound expands into detailed cache hierarchy analysis including L1 Bound, L2 Bound, L3 Bound, DRAM Bound, and Store Bound categories. Core Bound breaks down into execution unit constraints such as Divider and Ports Utilization, along with many other specific microarchitecture-level categories that enable precise performance tuning.
 
 ## Level 4: Access specific PMU counter events
 
-The final level provides direct access to the specific microarchitecture events that cause the inefficiencies. At this level, you work directly with raw PMU counter values to understand the underlying hardware behavior causing performance bottlenecks. This enables precise tuning by identifying exactly which execution units, cache levels, or pipeline stages are limiting performance, allowing you to apply targeted code optimizations or hardware configuration changes. 
+Level 4 provides direct access to the specific microarchitecture events that cause the inefficiencies. At this level, you work directly with raw PMU counter values to understand the underlying hardware behavior causing performance bottlenecks. This enables precise tuning by identifying exactly which execution units, cache levels, or pipeline stages are limiting performance, allowing you to apply targeted code optimizations or hardware configuration changes. 
 
 ## Apply essential Intel x86 PMU counters for analysis
 
@@ -63,5 +65,5 @@ Intel processors expose hundreds of performance events, but top-down analysis re
 | `OFFCORE_RESPONSE.*`                            | Detailed classification of off-core responses (L3 vs. DRAM, local vs. remote socket) |
 
 
-Using the above levels of metrics you can find out which of the four top-level categories are causing bottlenecks.
+Using the above levels of metrics, you can determine which of the four top-level categories are causing bottlenecks.
 

content/learning-paths/cross-platform/topdown-compare/1b-arm.md

@@ -1,5 +1,5 @@
 ---
-title: "Implement Arm Neoverse 2-stage top-down analysis"
+title: "Understand Arm Neoverse top-down analysis"
 weight: 5
 
 ### FIXED, DO NOT MODIFY
@@ -9,15 +9,15 @@ layout: learningpathall
 
 After understanding Intel's comprehensive 4-level hierarchy, you can explore how Arm approached the same performance analysis challenge with a different philosophy. Arm developed a complementary top-down methodology specifically for Neoverse server cores that prioritizes practical usability while maintaining analysis effectiveness.
 
-The Arm Neoverse architecture uses an 8-slot rename unit for pipeline bandwidth accounting, differing from Intel's issue-slot model. Unlike Intel's hierarchical model, Arm employs a streamlined two-stage methodology that balances analysis depth with practical usability.
+The Arm Neoverse architecture uses an 8-slot rename unit for pipeline bandwidth accounting, which differs from Intel's issue-slot model. Unlike Intel's hierarchical model, Arm employs a streamlined two-stage methodology that balances analysis depth with practical usability.
 
 ### Execute Stage 1: Calculate top-down performance categories
 
-Stage 1 identifies high-level bottlenecks using the same four categories as Intel but with Arm-specific PMU events and formulas. This stage uses slot-based accounting similar to Intel's approach while employing Arm event names and calculations tailored to the Neoverse architecture.
+Stage 1 identifies high-level bottlenecks using the same four categories as Intel, but with Arm-specific PMU events and formulas. This stage uses slot-based accounting similar to Intel's approach while employing Arm event names and calculations tailored to the Neoverse architecture.
 
 #### Configure Arm-specific PMU counter formulas
 
-Arm uses different top-down metrics based on different events but the concept remains similar to Intel's approach. The key difference lies in the formula calculations and slot accounting methodology:
+Arm uses different top-down metrics based on different events, but the concept remains similar to Intel's approach. The key difference lies in the formula calculations and slot accounting methodology:
 
 | Metric | Formula | Purpose |
 | :-- | :-- | :-- |
@@ -32,7 +32,9 @@ Stage 2 focuses on resource-specific effectiveness metrics grouped by CPU compon
 
 #### Navigate resource groups without hierarchical constraints
 
-Instead of Intel's hierarchical levels, Arm organizes detailed metrics into effectiveness groups that can be explored independently. **Branch Effectiveness** provides misprediction rates and MPKI, while **ITLB/DTLB Effectiveness** measures translation lookaside buffer efficiency. **Cache Effectiveness** groups (L1I/L1D/L2/LL) deliver cache hit ratios and MPKI across the memory hierarchy. Additionally, **Operation Mix** breaks down instruction types (SIMD, integer, load/store), and **Cycle Accounting** tracks frontend versus backend stall percentages.
+Instead of Intel's hierarchical levels, Arm organizes detailed metrics into effectiveness groups that can be explored independently. 
+
+**Branch Effectiveness** provides misprediction rates and MPKI, while **ITLB/DTLB Effectiveness** measures translation lookaside buffer efficiency. **Cache Effectiveness** groups (L1I/L1D/L2/LL) deliver cache hit ratios and MPKI across the memory hierarchy. Additionally, **Operation Mix** breaks down instruction types (SIMD, integer, load/store), and **Cycle Accounting** tracks frontend versus backend stall percentages.
 
 ## Apply essential Arm Neoverse PMU counters for analysis
 

content/learning-paths/cross-platform/topdown-compare/1c-compare-arch.md

@@ -13,7 +13,7 @@ After understanding each architecture's methodology individually, you can now ex
 - Hierarchical analysis: broad classification followed by drill-down into dominant bottlenecks
 - Resource attribution: map performance issues to specific CPU micro-architectural components
 
-## Compare 4-level hierarchical and 2-stage methodologies  
+## Compare multi-level hierarchical and resource groups methodologies  
 
 | Aspect | Intel x86 | Arm Neoverse |
 | :-- | :-- | :-- |

content/learning-paths/cross-platform/topdown-compare/2-code-examples.md

@@ -98,9 +98,9 @@ S0-D0-C1           1                 8.5%                 0.0%                 0
        6.052117775 seconds time elapsed
 ```
 
-You see a very large `backend bound` component for this program. 
+You see a very large `backend bound` component for this program.
 
-You can also run with the `-M topdownl1` argument on Perf. 
+You can also run with the `-M topdownl1` argument with Perf. 
 
 ```console
 taskset -c 1 perf stat -C 1 -M topdownl1  ./test 1000000000
@@ -129,21 +129,21 @@ Done. Final result: 0.000056
        6.029283206 seconds time elapsed
 ```
 
-Again, showing `Backend_Bound` value very high (0.96). Notice the x86-specific PMU counters:
+Again, showing a `Backend_Bound` value that is very high (0.96). Notice the x86-specific PMU counters:
 - `uops_issued.any` and `uops_retired.retire_slots` for micro-operation accounting
 - `idq_uops_not_delivered.core` for frontend delivery failures
 - `cpu_clk_unhalted.thread` for cycle normalization
 
 If you want to learn more, you can continue with the Level 2 and Level 3 hierarchical analysis.
 
 
-## Use the Arm Neoverse 2-stage top-down methodology
+## Use the Arm Neoverse top-down methodology
 
-Arm's approach uses a 2-stage methodology with PMU counters like `STALL_SLOT_BACKEND`, `STALL_SLOT_FRONTEND`, `OP_RETIRED`, and `OP_SPEC` for Stage 1 analysis, followed by resource effectiveness groups in Stage 2.
+Arm's approach uses a methodology with PMU counters like `STALL_SLOT_BACKEND`, `STALL_SLOT_FRONTEND`, `OP_RETIRED`, and `OP_SPEC` for Stage 1 analysis, followed by resource effectiveness groups in Stage 2.
 
 Make sure you install the Arm topdown-tool using the [Telemetry Solution install guide](/install-guides/topdown-tool/).
 
-Collect Stage 2 general metrics including Instructions Per Cycle (IPC):
+Collect general metrics including Instructions Per Cycle (IPC):
 
 ```console
 taskset -c 1 topdown-tool -m General ./test 1000000000
@@ -178,14 +178,14 @@ Frontend Stalled Cycles 0.04% cycles
 Backend Stalled Cycles. 88.15% cycles
 ```
 
-This confirms the example has high backend stalls equivalent to x86's Backend_Bound category. Notice how Arm's Stage 1 uses percentage of cycles rather than Intel's slot-based accounting. 
+This confirms the example has high backend stalls, equivalent to x86's Backend_Bound category. Notice how Arm's Stage 1 uses percentage of cycles rather than Intel's slot-based accounting. 
 
 You can continue to use the `topdown-tool` for additional microarchitecture exploration.
 
 For L1 data cache:
 
 ```console
-taskset -c 1 topdown-tool -m L1D_Cache_Effectiveness  ./test 1000000000
+taskset -c 1 topdown-tool -m L1D_Cache_Effectiveness ./test 1000000000
 ```
 
 The output is similar to:
@@ -203,7 +203,7 @@ L1D Cache Miss Ratio......... 0.000 per cache access
 For L1 instruction cache effectiveness:
 
 ```console
-taskset -c 1 topdown-tool -m L1D_Cache_Effectiveness  ./test 1000000000
+taskset -c 1 topdown-tool -m L1I_Cache_Effectiveness  ./test 1000000000
 ```
 
 The output is similar to:
@@ -213,9 +213,9 @@ Performing 1000000000 dependent floating-point divisions...
 Done. Final result: 0.000056
 Stage 2 (uarch metrics)
 =======================
-[L1 Data Cache Effectiveness]
-L1D Cache MPKI............... 0.022 misses per 1,000 instructions
-L1D Cache Miss Ratio......... 0.000 per cache access
+[L1 Instruction Cache Effectiveness]
+L1I Cache MPKI............... 0.022 misses per 1,000 instructions
+L1I Cache Miss Ratio......... 0.000 per cache access
 ```
 
 For last level cache: 
@@ -263,9 +263,11 @@ Crypto Operations Percentage........ 0.00% operations
 
 ## Cross-architecture performance analysis summary
 
-Both Arm Neoverse and modern x86 cores expose hardware PMU events that enable equivalent top-down analysis, despite different counter names and calculation methods. Intel x86 processors use a four-level hierarchical methodology based on slot-based pipeline accounting, relying on PMU counters such as `UOPS_RETIRED.RETIRE_SLOTS`, `IDQ_UOPS_NOT_DELIVERED.CORE`, and `CPU_CLK_UNHALTED.THREAD` to break down performance into retiring, bad speculation, frontend bound, and backend bound categories. Linux Perf serves as the standard collection tool, using commands like `perf stat --topdown` and the `-M topdownl1` option for detailed breakdowns.
+Both Arm Neoverse and modern x86 cores expose hardware PMU events that enable equivalent top-down analysis, despite different counter names and calculation methods. 
+
+Intel x86 processors use a four-level hierarchical methodology based on slot-based pipeline accounting, relying on PMU counters such as `UOPS_RETIRED.RETIRE_SLOTS`, `IDQ_UOPS_NOT_DELIVERED.CORE`, and `CPU_CLK_UNHALTED.THREAD` to break down performance into retiring, bad speculation, frontend bound, and backend bound categories. Linux Perf serves as the standard collection tool, using commands like `perf stat --topdown` and the `-M topdownl1` option for detailed breakdowns.
 
 Arm Neoverse platforms implement a complementary two-stage methodology where Stage 1 focuses on topdown categories using counters such as `STALL_SLOT_BACKEND`, `STALL_SLOT_FRONTEND`, `OP_RETIRED`, and `OP_SPEC` to analyze pipeline stalls and instruction retirement. Stage 2 evaluates resource effectiveness, including cache and operation mix metrics through `topdown-tool`, which accepts the desired metric group via the `-m` argument.
 
-Both architectures identify the same performance bottleneck categories, enabling similar optimization strategies across Intel and Arm platforms while accounting for methodological differences in measurement depth and analysis approach. 
+Both architectures identify the same performance bottleneck categories, enabling similar optimization strategies across Intel and Arm platforms while accounting for methodological differences in measurement depth and analysis approach.
 

content/learning-paths/cross-platform/topdown-compare/_index.md

@@ -1,16 +1,12 @@
 ---
 title: Compare Arm Neoverse and Intel x86 top-down performance analysis with PMU counters 
 
-draft: true
-cascade:
-    draft: true
-
 minutes_to_complete: 30
 
 who_is_this_for: This is an advanced topic for software developers and performance engineers who want to understand the similarities and differences between Arm Neoverse and Intel x86 top-down performance analysis using PMU counters, Linux Perf, and the topdown-tool. 
 
 learning_objectives:
-     - Compare Intel x86 4-level hierarchical top-down methodology with Arm Neoverse 2-stage approach using PMU counters
+     - Compare Intel x86 multi-level hierarchical methodology with Arm Neoverse micro-architecture exploration methodology
      - Execute performance analysis using Linux Perf on x86 and topdown-tool on Arm systems
      - Analyze Backend Bound, Frontend Bound, Bad Speculation, and Retiring categories across both architectures