On 11/25/2014 01:57 PM, Rik van Riel wrote: > On 11/25/2014 12:21 PM, Marcelo Tosatti wrote: >> The problem: >> >> On -RT, an emulated LAPIC timer instances has the following path: >> >> 1) hard interrupt >> 2) ksoftirqd is scheduled >> 3) ksoftirqd wakes up vcpu thread >> 4) vcpu thread is scheduled >> >> This extra context switch introduces unnecessary latency in the >> LAPIC path for a KVM guest. >> >> The solution: >> >> Allow waking up vcpu thread from hardirq context, >> thus avoiding the need for ksoftirqd to be scheduled. >> >> Normal waitqueues make use of spinlocks, which on -RT >> are sleepable locks. Therefore, waking up a waitqueue >> waiter involves locking a sleeping lock, which >> is not allowed from hard interrupt context. >> > > What are the consequences for the realtime kernel of > making waitqueue traversal non-preemptible? > > Is waitqueue traversal something that ever takes so > long we need to care about it being non-preemptible? I answered my own question. This patch only changes the kvm vcpu waitqueue, which should only ever have the vcpu thread itself waiting on it. In other words, it is a wait "queue" of just one entry long, and the latency of traversing it will be absolutely minimal. Unless someone can think of a better way to implement this patch, it gets my: Acked-by: Rik van Riel <riel@xxxxxxxxxx> -- 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
