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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1011792 Title: Kernel lockup running 3.0.0 and 3.2.0 on multiple EC2 instance types To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1011792/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
