mirror of
https://github.com/gatieme/LDD-LinuxDeviceDrivers.git
synced 2026-09-25 23:03:34 +08:00
arch: topdown
This commit is contained in:
Cheng Jian
@@ -37,21 +37,13 @@ blogexcerpt: 虚拟化 & KVM 子系统
|
||||
|
||||
自顶向下的微架构分析方法(Top-Down Microarchitecture)
|
||||
|
||||
|
||||
| 类型 | 描述 |
|
||||
|:---:|:----:|
|
||||
| Retiring | 正常执行 |
|
||||
| Bad Speculation | 投机错误 |
|
||||
|
|
||||
|
||||
|
||||
# 2 背景知识解析
|
||||
-------
|
||||
|
||||
| 类型 | 描述 |
|
||||
|:---:|:----:|
|
||||
| [uOps](https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/reference/cpu-metrics-reference/uops.html) | micro-ops/micro-operations/微指令 是一种底层硬件操作, CPU 前端负责获取体系结构指令中表示的程序代码, 并将其解码为一个或多个 uops. |
|
||||
| [Pipeline Slots](https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/reference/cpu-metrics-reference/pipeline-slots.html) | 一个 pipeline slot 表示处理一个 uOp 需要的硬件资源. Top-Down 分析方法假定对于每个 CPU 核, 在每个时钟周期, 有多个可用的 Pipeline Slots. 这些 Pipeline Slots 的数量被称为 Pipeline Width. |
|
||||
| [Pipeline Slots](https://www.intel.com/content/www/us/en/develop/documentation/vtune-help/top/reference/cpu-metrics-reference/pipeline-slots.html) | Pipeline Slot(流水线槽) 代表着一个 uOps 所需的硬件资源. Top-Down 分析方法假定对于每个 CPU 核, 在每个时钟周期, 有多个可用的 Pipeline Slots. 这些 Pipeline Slots 的数量被称为 Pipeline Width. |
|
||||
|
||||
## 2.1 uOps
|
||||
-------
|
||||
@@ -86,16 +78,51 @@ blogexcerpt: 虚拟化 & KVM 子系统
|
||||
可见, 与以 Pipeline Slots 测量的指标相比, 以 Clockticks 测量的指标不太精确. 但是, 此类指标对于识别代码中的主要性能瓶颈仍然很有用.
|
||||
|
||||
|
||||
|
||||
# 3 分析
|
||||
-------
|
||||
|
||||
|
||||
| 类型 | 描述 |
|
||||
|:---:|:----:|
|
||||
| Front-End/前端 | 负责获取程序代码指令, 并将其解码为一个或者多个微操作(uOps), 这些 uOps 将分配给 Back-End 去执行.<br>Front-end 负责交付 uOps 给 Back-end 执行. Front-end 从 Icache 中提取代码字节流到流水线, 通过分支预测器预测下一个地址以进行提取. 将代码字节分割成指令, 并发送给解码器, 解码器将指令解码到 uOps(mirco-ops), 以便交给 Back-end 执行. |
|
||||
| Back-end/后端 | 负责监控 uOps 的数据何时可用, 并将其安排到可用的执行单元中执行. |
|
||||
| Speculation/预测 | 部分跳转指令可能需要对跳转方向和跳转地址进行预测. 通常情况下, 大多数 uOps 都会通过流水线并正常退役, 但是在预测错误的情况下, 投机执行的 uOps 可能会在退役前被取消并从流水线中清楚掉. |
|
||||
| Retirement/退役 | uOps 执行完成. 这被称为退役 |
|
||||
|
||||
|
||||
|
||||
|
||||
| 类型 | 描述 |
|
||||
|:---:|:----:|
|
||||
| Front-End Bound | 表示 pileline 不足以供应 Back-end. 也就是说当 Back-end 准备接收 uOps 时, Pipeline Slots 出现了 stall. Front-End Bound 可以进一步分为:<br>1. Fetch Latency Bound: icache/tlb miss<br>2. Fetch Bandwidth Bound: sub-optimal decoding. |
|
||||
| Back-end Bound | 表示由于缺乏 uOps 执行所需的后端资源造成的停顿. 它可以进一步细分为:<br>1. Memory Bound: 由内存子系统造成的停顿卡顿.<br>2. Core Bound: 执行单元压力 Compute Bound 或者去缺少指令集并行 LTP.<br>3. Resource Bound |
|
||||
| Bad Speculation | 由于分支预测错误导致的 Pipeline Slot 被浪费. 主要包括 Front-End 最终被取消的 uOps 的 pipeline Slots, 以及 Back End 过程中由于从先前错误的猜测中恢复而阻塞造成的 Pipeline Slot. |
|
||||
| Retring | 表示运行有效的 PileSlots. |
|
||||
|
||||
|
||||
理想情况下, 我们希望所有看到的 Pileline Slot 都归类到 Retring. 因为他与 IPC 息息相关.
|
||||
如果一个 Pipeline Slot 被某个 uOps 占用, 它将被分类到 Retring 或者 Bad Speculation, 具体取决于他是否被提交.
|
||||
如果 Pipeline 被某个 Back-end 阶段 Pipeline Slot 都被占用, 无法接受更多的操作. 则未被利用的 Pileline Slot 就被归类为 Back-end Bound.
|
||||
同样 Front-End Bound 则表示在没有 Back-end Stall 的情况下, 没有更多的 uOps 被分配给后端去处理.
|
||||
|
||||
在目前比较常见的 Intel X86_64 的微架构实现上, 流水线的 Front-end 每个 cycle 可以分配 4 个 uOps, 同样 Back-end 也可以在每个 cycle 中退役 4 个 uOps.
|
||||
于是 TMAM 假定对于每个 CPU 核, 在每个 cycle, 均有 4 个 Pipeline Slot 可用, 然后使用一些自定义的 PMU 事件来测量这些 pipeline slot 的使用情况.
|
||||
|
||||
在每个 CPU 周期中, pipeline slot 可以是空的或者被 uOp 填充. 如果在一个 CPU 周期内某个 pipeline slot 是空的, 称之为一次停顿(stall). 如果 CPU 经常停顿, 系统性能肯定是受到影响的. TMAM 的目标就是确定系统性能问题的主要瓶颈.
|
||||
|
||||
|
||||
# 1 参考资料
|
||||
-------
|
||||
|
||||
| 编号 | 链接 | 描述 |
|
||||
|:---:|:----:|:---:|
|
||||
| 1 | [A Journey Through the CPU Pipeline](https://www.gamedev.net/tutorials/_/technical/general-programming/a-journey-through-the-cpu-pipeline-r3115) | 讲述了 CPU 流水线的前世今生(不断演进和完善) |
|
||||
| 1 | [A Journey Through the CPU Pipeline](https://bryanwagstaff.com/index.php/a-journey-through-the-cpu-pipeline/) | 讲述了 CPU 流水线的前世今生(不断演进和完善), [翻译版本](https://kb.cnblogs.com/page/179578) |
|
||||
| 2 | [Top-down Microarchitecture Analysis Method](https://www.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/methodologies/top-down-microarchitecture-analysis-method.html) |
|
||||
| 3 | [A Top-Down method for performance analysis and counters architecture](https://www.researchgate.net/publication/269302126_A_Top-Down_method_for_performance_analysis_and_counters_architecture) | Intel 关于 topdown 分析方法的论文, 以及 [slide](https://pdfs.semanticscholar.org/b5e0/1ab1baa6640a39edfa06d556fabd882cdf64.pdf) |
|
||||
| 4 |
|
||||
|
||||
| 4 | [Intel P4 CPU](https://www.cnblogs.com/linhaostudy/p/9204107.html) | |
|
||||
| 5 | [The Berkeley Out-of-Order Machine (BOOM)](https://docs.boom-core.org/en/latest/sections/intro-overview/boom.html) | |
|
||||
| 6 | [Top-down Microarchitecture Analysis through Linux perf and toplev tools](http://www.cs.technion.ac.il/~erangi/TMA_using_Linux_perf__Ahmad_Yasin.pdf)
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user