From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu->wq Date: Tue, 25 Nov 2014 14:08:15 -0500 Message-ID: <5474D39F.4010206@redhat.com> References: <20141125172108.992070524@redhat.com> <20141125172329.435080075@redhat.com> <5474D121.4070905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Luiz Capitulino , Steven Rostedt , Thomas Gleixner , kvm@vger.kernel.org To: Marcelo Tosatti , linux-kernel@vger.kernel.org Return-path: In-Reply-To: <5474D121.4070905@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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