On Thu, Sep 27, 2012 at 12:04:58PM +0200, Avi Kivity wrote: > On 09/27/2012 11:58 AM, Gleb Natapov wrote: > > > >> > > >> >> btw, we can have secondary effects. A vcpu can be waiting for a lock in > >> >> the host kernel, or for a host page fault. There's no point in boosting > >> >> anything for that. Or a vcpu in userspace can be waiting for a lock > >> >> that is held by another thread, which has been preempted. > >> > Do you mean userspace spinlock? Because otherwise task that's waits on > >> > a kernel lock will sleep in the kernel. > >> > >> I meant a kernel mutex. > >> > >> vcpu 0: take guest spinlock > >> vcpu 0: vmexit > >> vcpu 0: spin_lock(some_lock) > >> vcpu 1: take same guest spinlock > >> vcpu 1: PLE vmexit > >> vcpu 1: wtf? > >> > >> Waiting on a host kernel spinlock is not too bad because we expect to be > >> out shortly. Waiting on a host kernel mutex can be a lot worse. > >> > > We can't do much about it without PV spinlock since there is not > > information about what vcpu holds which guest spinlock, no? > > It doesn't help. If the lock holder is waiting for another lock in the > host kernel, boosting it doesn't help even if we know who it is. We > need to boost the real lock holder, but we have no idea who it is (and > even if we did, we often can't do anything about it). > Without PV lock we will boost random preempted vcpu instead of going to sleep in the situation you described. -- Gleb. -- 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
