From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751495AbdIWNl1 (ORCPT ); Sat, 23 Sep 2017 09:41:27 -0400 Received: from merlin.infradead.org ([205.233.59.134]:59190 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750769AbdIWNl0 (ORCPT ); Sat, 23 Sep 2017 09:41:26 -0400 Date: Sat, 23 Sep 2017 15:41:14 +0200 From: Peter Zijlstra To: Paolo Bonzini Cc: Marcelo Tosatti , Konrad Rzeszutek Wilk , mingo@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall Message-ID: <20170923134114.qdfdegrd6afqrkut@hirez.programming.kicks-ass.net> References: <20170921113835.031375194@redhat.com> <20170921114039.466130276@redhat.com> <20170921133653.GO26248@char.us.oracle.com> <20170921140628.zliqlz7mrlqs5pzz@hirez.programming.kicks-ass.net> <20170922011039.GB20133@amt.cnet> <20170922100004.ydmaxvgpc2zx7j25@hirez.programming.kicks-ass.net> <20170922105609.deln6kylvvpaijg7@hirez.programming.kicks-ass.net> <20170922123305.GB29608@amt.cnet> <20170922125556.cyzybj6c7jqypbmo@hirez.programming.kicks-ass.net> <951aaa3f-b20d-6f67-9454-f193f4445fc7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <951aaa3f-b20d-6f67-9454-f193f4445fc7@redhat.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 23, 2017 at 12:56:12PM +0200, Paolo Bonzini wrote: > On 22/09/2017 14:55, Peter Zijlstra wrote: > > You just explained it yourself. If the thread that needs to complete > > what you're waiting on has lower priority, it will _never_ get to run if > > you're busy waiting on it. > > > > This is _trivial_. > > > > And even for !RT it can be quite costly, because you can end up having > > to burn your entire slot of CPU time before you run the other task. > > > > Userspace spinning is _bad_, do not do this. > > This is not userspace spinning, it is guest spinning---which has > effectively the same effect but you cannot quite avoid. So I'm virt illiterate and have no clue on how all this works; but wasn't this a vmexit ? (that's what marcelo traced). And once you've done a vmexit you're a regular task again, not a vcpu. > But I agree that the solution is properly prioritizing threads that can > interrupt the VCPU, and using PI mutexes. Right, if you want to run RT VCPUs the whole emulator/vcpu interaction needs to be designed for RT. > I'm not a priori opposed to paravirt scheduling primitives, but I am not > at all sure that it's required. Problem is that the proposed thing doesn't solve anything. There is nothing that prohibits the guest from triggering a vmexit while holding a spinlock and landing in the self-same problems.