On 09/25/2012 04:21 PM, Takuya Yoshikawa wrote: > On Tue, 25 Sep 2012 10:12:49 +0200 > Avi Kivity <avi@xxxxxxxxxx> wrote: > >> It will. The tradeoff is between false-positive costs (undercommit) and >> true positive costs (overcommit). I think undercommit should perform >> well no matter what. >> >> If we utilize preempt notifiers to track overcommit dynamically, then we >> can vary the spin time dynamically. Keep it long initially, as we get >> more preempted vcpus make it shorter. > > What will happen if we pin each vcpu thread to some core? > I don't want to see so many vcpu threads moving around without > being pinned at all. If you do that you've removed a lot of flexibility from the scheduler, so overcommit becomes even less likely to work well (a trivial example is pinning two vcpus from the same vm to the same core -- it's so obviously bad no one considers doing it). > In that case, we don't want to make KVM do any work of searching > a vcpu thread to yield to. Why not? If a vcpu thread on another core has been preempted, and is the lock holder, and we can boost it, then we've fixed our problem. Even if the spinning thread keeps spinning because it is the only task eligible to run on its core. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
