问题
I run a SPECJbb benchmark in my KVM virtual machine. It shows a drastic drop on throughput between Warehouse 2 and Warehouse 3(The different between them is just addding on cocurrent task)
Then I use perf in my guest virtual machine. It shows that _spin_unlock_irqrestore has very high sampling rate.
Events: 31K cycles
74.89% [kernel] [k] _spin_unlock_irqrestore
7.36% perf-1968.map [.] 0x7f84b913e064
6.82% [kernel] [k] __do_softirq
6.39% [kernel] [k] handle_IRQ_event
...
It seems that only 7.36% cpu time running my Java program. Why _spin_unlock_irqrestore's sampling rate is so high? And what does it do?
回答1:
It's bad reporting by perf, not cycles consumed by _spin_unlock_irqrestore.
When IRQs are disabled, perf's interrupts are not processed. Instead, they're processed when interrupts are re-enabled. When perf's interrupt handler looks at the instruction pointer, to see what code was running, it finds the function that enabled interrupts - quite often it's _spin_unlock_irqrestore.
So all you know is that the cycles were consumed by code that had interrupts disabled, and enabled them using _spin_unlock_irqrestore.
If you can get perf to use NMI (non maskable interrupt), it could solve this problem.
I know that it can be done with oprofile (perf's predecessor) by changing the makefile, but don't know about perf.
来源：https://stackoverflow.com/questions/14703328/spin-unlock-irqrestore-has-very-high-sampling-rate-in-my-kvm-why