Geek Answers Handbook

_spin_unlock_irqrestore () has a very high sampling rate in my kvm, why?

I run the SPECJbb test on my KVM virtual machine. This shows a sharp drop in throughput between Warehouse 2 and Warehouse 3 (The difference between them is just an addition to the parallel task)

Then I use perf in the guest virtual machine. This shows that _spin_unlock_irqrestore has a 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

...

Only 7.36% of the CPU time seems to work with my Java program. Why is the _spin_unlock_irqrestore sample rate so high? And what is he doing?

+4
source share
1 answer

Poor reporting perf , not the cycles consumed by _spin_unlock_irqrestore .

When IRQs are disabled, perforated interrupts are not processed. Instead, they are processed when interrupts are re-enabled. When the persistent interrupt handler looks at the instruction pointer to see which code has been run, it finds a function that allows interrupts - often this is _spin_unlock_irqrestore .

So, all you know is that the loops were destroyed by code that disabled interrupts and turned them on using _spin_unlock_irqrestore .

If you can force perf to use NMI (non-maskable interrupt), this can solve this problem.
I know that this can be done using oprofile (the predecessor) by changing the makefile, but I don't know about perf.

+6
source

More articles:


All Articles