Messages in this thread |  | | Date | Sun, 30 Sep 2012 10:24:51 +0200 | | From | Avi Kivity <> | | Subject | Re: [PATCH RFC 0/2] kvm: Improving undercommit,overcommit scenarios in PLE handler |
| |
On 09/28/2012 01:40 PM, Andrew Theurer wrote: >> >> >> >> >> IIRC, with defer preemption : >> >> we will have hook in spinlock/unlock path to measure depth of lock held, >> >> and shared with host scheduler (may be via MSRs now). >> >> Host scheduler 'prefers' not to preempt lock holding vcpu. (or rather >> >> give say one chance. >> > >> > A downside is that we have to do that even when undercommitted. > > Hopefully vcpu preemption is very rare when undercommitted, so it should > not happen much at all.
As soon as you're preempted, you're effectively overcommitted (even if the system as a whole is undercommitted). What I meant was that you need to communicate your lock state to the host, and with fine-grained locking this can happen a lot. It may be as simple as an increment/decrement instruction though.
-- error compiling committee.c: too many arguments to function
|  |