Description of problem: When the total number of vcpu's on a host is larger than the number of physical processors, there is the possibility that a vcpu on a multi cpu guest will be preempted by the hypervisor while the vcpu holds a kernel lock. Then other vcpu's on the guest that are trying to acquire the lock simply spin. The customer is currently adjusting the real time priority and using the nice command to shorten the time slice of the qemu on the host. They feel this does help improve performance in these situations. They have asked us to include something like this part of an official maintenance release of RHEL 5. They are wanting it addressed in RHEL 5 because “over-provisioning is one of the features users like to exploit on virtualization.” I have discussed this briefly with Chris Wright and he agreed a BZ should be opened to address this.
Event posted on 09-28-2009 10:43am EDT by Glen Johnson ------- Comment From lnx1138.ibm.com 2009-09-28 10:40 EDT------- Has Red Hat had a chance to try the additional performance tests as suggested by Andrew? This event sent from IssueTracker by jkachuck issue 338069
Does guest spin lock detector backport is enough here or do we need any potential scheduler setting changed? IMO the first should be enough, at least for a start
The backport deadlocks ;-(
Event posted on 12-14-2009 10:04am EST by Glen Johnson ------- Comment From habanero.com 2009-12-14 09:56 EDT------- I recommend we close this bug as will_not_fix and focus on Red Hat 6 to ensure we have no issues there. For 5.x, I suggest we encourage customers to use 1-way VMs first, and only use SMP VMs when absolutely necessary. This event sent from IssueTracker by jkachuck issue 338069