Messages in this thread | | | Date | Mon, 24 Sep 2012 18:06:54 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler |
| |
On 09/24/2012 05:41 PM, Avi Kivity wrote: > >> >> case 2) >> rq1 : vcpu1->wait(lockA) (spinning) >> rq2 : vcpu3 (running) , vcpu2->holding(lockA) [scheduled out] >> >> I agree that checking rq1 length is not proper in this case, and as you >> rightly pointed out, we are in trouble here. >> nr_running()/num_online_cpus() would give more accurate picture here, >> but it seemed costly. May be load balancer save us a bit here in not >> running to such sort of cases. ( I agree load balancer is far too >> complex). > > In theory preempt notifier can tell us whether a vcpu is preempted or > not (except for exits to userspace), so we can keep track of whether > it's we're overcommitted in kvm itself. It also avoids false positives > from other guests and/or processes being overcommitted while our vm is fine.
It also allows us to cheaply skip running vcpus.
We would probably need a ->sched_exit() preempt notifier to make this work. Peter, I know how much you love those, would it be acceptable? We'd still need yield_to() but the pressure on it might be reduced.
-- error compiling committee.c: too many arguments to function
| |