应展示IPC总和随逻辑线程数增加而异常下降的曲线，并叠加frontend-stalls、branch-misses等前端瓶颈指标同步飙升，证明HT下前端资源共享导致指令执行效率骤降。
在面试中，用性能曲线证明程序计数器（PC）在超线程（Hyper-Threading, HT）架构下的调度瓶颈，关键不是画一条“PC变化曲线”，而是展示指令执行效率随逻辑核密度上升而异常下降的证据链——因为现代CPU中，程序计数器本身不参与调度决策，但它所指向的指令流执行状态，会通过硬件事件（如分支预测失败、重排序缓冲区溢出、前端停滞周期）暴露HT资源争抢的真实瓶颈。
聚焦可测量的前端瓶颈指标
超线程共享同一物理核心的前端（取指、译码、分支预测）和部分后端资源。当两个逻辑核同时活跃时，PC跳转密集、分支高度不可预测的负载（如复杂控制流的Java服务或Python解释器循环）会加剧前端竞争。应优先采集以下perf事件并绘制成随并发线程数增加的曲线：
- frontend-stalls-cycles：前端停滞周期占比（越接近100%，说明取指/译码被阻塞越严重）
- branch-misses：分支预测失败率（HT下共享分支预测器，冲突上升时该值陡增）
- idq_uops_not_delivered.core（Intel）或 lsd_cycles_active：表明微指令队列交付不足或循环流检测器过载
- 对比组：固定1个物理核，分别跑1线程 vs 2线程（HT开启），横轴为线程数，纵轴为上述事件每周期发生频次
用“反常缩放比”替代PC曲线
不要试图追踪PC寄存器值的变化——它每条指令都在变，无分析价值。真正能说明HT调度瓶颈的是性能缩放失效现象：
- 在单物理核上，1线程运行时IPC（Instructions Per Cycle）= 1.8；开启HT跑2线程，若IPC总和仅为2.2（远低于3.6的理想线性叠加），说明存在严重资源争抢
- 此时绘制IPC总和曲线：X轴为逻辑线程数（1→2），Y轴为总IPC，出现明显“拐点下降”或“增长趋缓”，配合frontend-stalls同步飙升，即可归因为HT前端调度饱和
- 进一步佐证：关闭HT再测，同样2线程（需绑定到2个不同物理核）IPC总和接近3.4，说明问题确由HT资源共享引发，而非代码本身
关联调度延迟与PC相关行为
虽然PC不直接参与调度，但内核调度器在上下文切换时需保存/恢复RIP（x86-64中PC的寄存器名）。在HT高争抢场景下，可观察到间接影响：
- 使用perf record -e sched:sched_switch,sched:sched_migrate_task采集调度事件，统计单位时间内的上下文切换次数
- 当HT争抢严重时，线程频繁因前端阻塞而进入TASK_INTERRUPTIBLE状态，触发更多自愿切换；同时，调度器可能因感知到某逻辑核“空转但未完成工作”而主动迁移任务，导致RIP保存/恢复开销上升
- 将sched_switch频率曲线与frontend-stalls曲线叠图，若二者同步尖峰，可说明HT调度瓶颈已传导至调度层行为异常
本质上，你不是在证明“PC被卡住”，而是在用硬件事件曲线证明：超线程环境下，前端取指与控制流处理能力已成为瓶颈，而PC所代表的指令流推进节奏，正是这一瓶颈最敏感的外在表征。
