有谁知道为什么perf总是显示_raw_spin_unlock_irqrestore或其他一些旋转解锁功能?与spin_lock相比,spin_unlock实现通常更简单。如果spin_lock上存在高争用,那么perf是否应该在spin_lock中显示结果?
答案 0 :(得分:3)
禁用中断时,用于采样的计时器中断perf
不会触发。当最终启用中断(在任何irqrestore
函数中)时,perf
会错误地计算整个时间范围,就像该恢复功能占用了整个时间范围一样。
如果您使用perf annotate
进行更深入的研究,您会发现大多数(如果不是全部)样本是popfq
之后的1个操作码,它会更新EFLAGS寄存器并启用中断:< / p>
_raw_spin_unlock_irqrestore /proc/kcore
Percent│ Disassembly of section load0:
│
│ ffffffff819bd790 <load0>:
│ nop
│ push %rbp
│ mov %rsp,%rbp
│ movb $0x0,(%rdi)
│ nop
│ mov %rsi,%rdi
│ push %rdi
│ popfq
100.00 │ nop
│ pop %rbp
│ ← retq
Linux tries to use an NMI用于性能监视中断。自v2.6.31〜以来,此更改已进入主线,但我想这是针对裸机内核,而不是针对作为VM运行的内核(即,我的裸机Linux机器上的perf record
并没有出现此问题,而{{ 1}}在我的计算机上运行的KVM上)。
有关更多详细信息,请参见this answer。
答案 1 :(得分:1)
你在运行什么工作负载?你确定首先存在争议吗?
irq_restore显示,因为重新启用中断的代价很高,但是使用中断的锁不会经常出现。当机器大部分闲置时,你最有可能看到它。
对于踢,我跑了一个微不足道的工作量,争论一个自旋锁,并且毫无疑问这是锁定程序,它出现了最多:
81.36% [kernel] [k] native_queued_spin_lock_slowpath
4.67% libc-2.17.so [.] __memset_sse2
1.63% [kernel] [k] find_next_zero_bit
0.92% [kernel] [k] _raw_spin_lock
0.81% [kernel] [k] __audit_syscall_exit
0.76% [kernel] [k] __alloc_fd
0.69% [kernel] [k] __slab_free
0.62% [kernel] [k] security_compute_sid.part.13
0.45% [kernel] [k] kmem_cache_free
答案 2 :(得分:1)
本月的@employee 我的性能最高结果的片段
3.32% [kernel] [k] native_queued_spin_lock_slowpath
3.18% [kernel] [k] update_load_avg
3.13% [kernel] [k] __switch_to
3.12% [kernel] [k] native_write_msr
3.02% [kernel] [k] __sched_text_start
2.81% [kernel] [k] _raw_spin_lock
2.20% [kernel] [k] _raw_spin_lock_irqsave
1.97% [kernel] [k] switch_mm_irqs_off
1.70% [kernel] [k] __blkdev_direct_IO_simple
1.69% [kernel] [k] __get_user_pages_fast
这是我的FrameGraph结果 enter image description here