From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934740AbdIYKlW (ORCPT ); Mon, 25 Sep 2017 06:41:22 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:44609 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934336AbdIYKlU (ORCPT ); Mon, 25 Sep 2017 06:41:20 -0400 Date: Mon, 25 Sep 2017 12:41:09 +0200 (CEST) From: Thomas Gleixner To: Marcelo Tosatti cc: Peter Zijlstra , Konrad Rzeszutek Wilk , mingo@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall\ In-Reply-To: <20170925022238.GB5140@amt.cnet> Message-ID: 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> <20170922121640.GA29589@amt.cnet> <20170922123107.fjh2yfwnej73trim@hirez.programming.kicks-ass.net> <20170922124005.GA30393@amt.cnet> <20170922130141.tz6f4gktihmbhqli@hirez.programming.kicks-ass.net> <20170925022238.GB5140@amt.cnet> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 24 Sep 2017, Marcelo Tosatti wrote: > On Fri, Sep 22, 2017 at 03:01:41PM +0200, Peter Zijlstra wrote: > What the patch does is the following: > It reduces the window where SCHED_FIFO is applied vcpu0 > to those were a spinlock is shared between -RT vcpus and vcpu0 > (why: because otherwise, when the emulator thread is sharing a > pCPU with vcpu0, its unable to generate interrupts vcpu0). > > And its being rejected because: > Please fill in. Your patch is just papering over one particular problem, but it's not fixing the root cause. That's the worst engineering approach and we all know how fast this kind of crap falls over. There are enough other issues which can cause starvation of the RT VCPUs when the housekeeping VCPU is preempted, not just the particular problem which you observed. Back then when I did the first prototype of RT in KVM, I made it entirely clear, that you have to spend one physical CPU for _each_ VCPU, independent whether the VCPU is reserved for RT workers or the housekeeping VCPU. The emulator thread needs to run on a separate physical CPU. If you want to run the housekeeping VCPU and the emulator thread on the same physical CPU then you have to make sure that both the emulator and the housekeeper side of affairs are designed and implemented with RT in mind. As long as that is not the case, you simply cannot run them on the same physical CPU. RT is about guarantees and guarantees cannot be achieved with bandaid engineering. It's that simple, end of story. Thanks, tglx