gpt4 book ai didi

linux - Perf 启动开销 : Why does a simple static executable which performs MOV + SYS_exit have so many stalled cycles (and instructions)?

转载 作者:IT王子 更新时间:2023-10-29 00:01:44 27 4
gpt4 key购买 nike

我试图了解如何衡量性能并决定编写非常简单的程序:

section .text
global _start

_start:
mov rax, 60
syscall

然后我用 perf stat ./bin 运行了程序。令我惊讶的是 stalled-cycles-frontend 太高了。

      0.038132      task-clock (msec)         #    0.148 CPUs utilized          
0 context-switches # 0.000 K/sec
0 cpu-migrations # 0.000 K/sec
2 page-faults # 0.052 M/sec
107,386 cycles # 2.816 GHz
81,229 stalled-cycles-frontend # 75.64% frontend cycles idle
47,654 instructions # 0.44 insn per cycle
# 1.70 stalled cycles per insn
8,601 branches # 225.559 M/sec
929 branch-misses # 10.80% of all branches

0.000256994 seconds time elapsed

据我了解,stalled-cycles-frontend 意味着 CPU 前端必须等待某些操作(例如总线事务)的结果完成。

那么,在这种最简单的情况下,是什么导致 CPU 前端大部分时间都在等待?

还有 2 个页面错误?为什么?我没有阅读内存页。

最佳答案

页面错误包括代码页。

perf stat 包括启动开销。

IDK 了解 perf 如何开始计数的细节,但大概它必须在内核模式下对性能计数器进行编程,所以它们正在计数 同时 CPU 切换回用户模式(停滞许多周期,尤其是在具有使 TLB 无效的熔断防御的内核上)。

我想记录的大部分 47,654 指令都是内核代码。也许包括页面错误处理程序!

我猜你的进程永远不会走user->kernel->user,整个过程就是kernel->user->kernel(启动,syscall调用sys_exit,然后永远不会返回到用户空间),所以永远不会有 TLB 无论如何都会很热的情况,除非在 sys_exit 系统调用之后在内核中运行。无论如何,TLB 未命中不是页面错误,但这可以解释许多停滞的周期。

用户->内核转换本身解释了大约 150 个停滞周期,顺便说一句。 syscall 比缓存未命中更快(除了它不是流水线,实际上刷新整个流水线;即特权级别未重命名。)


使用 perf stat --all-user 仅在用户空间中计数。

perf stat -e task-clock,cycles:u,instructions:u,cycles:k,instructions:k 编程四个计数器,两个计数 instructionscycles 事件只在用户模式下,两个只在内核模式下计数。 (PMU 对此提供硬件支持,因此用户空间的计数非常准确,仅相差一两条指令。)

另见

关于linux - Perf 启动开销 : Why does a simple static executable which performs MOV + SYS_exit have so many stalled cycles (and instructions)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48809347/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com