Comment 65 for bug 1011792

I just put a test1 version of a kernel to the same place as the nospinlock one. From my tests it seems that the problem in the Xen paravirt spinlock implementation is the fact that they re-enable interrupts (xen upcall event channel for that vcpu) during the hypercall to poll for the spinlock irq. If that also works on the production load, it would be better suited for a SRU as this only changes Xen code, while disabling sparavirt spinlocks also would change behaviour for KVM.

Then I would only need a good explanation of why exactly this is happening to argue with upstream... Oh, right, when testing the test1 kernel, maybe you could also have an eye on any possible side effects. Like is that instance showing drastically different performance or periods of delay?