From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751536AbdJBMaj (ORCPT ); Mon, 2 Oct 2017 08:30:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41390 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751128AbdJBMah (ORCPT ); Mon, 2 Oct 2017 08:30:37 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 70A4964108 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall\ To: Marcelo Tosatti Cc: Peter Zijlstra , Konrad Rzeszutek Wilk , mingo@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner References: <20170925091316.bnwpiscs2bvpdxk5@hirez.programming.kicks-ass.net> <00ff8cbf-4e41-a950-568c-3bd95e155d4b@redhat.com> <20170926224925.GA9119@amt.cnet> <6f4afefd-8726-13ff-371e-0d3896b4cf6a@redhat.com> <20170928004452.GA30040@amt.cnet> <10635834-459a-9ec1-624d-febd6b5af243@redhat.com> <20170928213508.GA14053@amt.cnet> <06b714d8-7b66-6e03-a992-e359241abf84@redhat.com> <20170929164006.GC29391@amt.cnet> <20170929201747.GB12447@amt.cnet> From: Paolo Bonzini Message-ID: <7bef8150-724f-7021-2a7b-cdc3e193b4c9@redhat.com> Date: Mon, 2 Oct 2017 14:30:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170929201747.GB12447@amt.cnet> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 02 Oct 2017 12:30:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/09/2017 22:17, Marcelo Tosatti wrote: > On Fri, Sep 29, 2017 at 07:05:41PM +0200, Paolo Bonzini wrote: >> On 29/09/2017 18:40, Marcelo Tosatti wrote: >>> Thats not the state of things (userspace in vcpu-0 is not specially tailored >>> to not violate latencies in vcpu-1): that is not all user triggered >>> actions can be verified. >>> >>> Think "updatedb", and so on... >> >> _Which_ spinlock is it that can cause unwanted latency while running >> updatedb on VCPU0 and a real-time workload on VCPU1, and only so on virt >> because of the emulator thread? > > Hundreds of them (the one being hit is in timer_interrupt), but i went > to check and there are hundreds of raw spinlocks shared between the > kernel threads that run on isolated CPUs and vcpu-0. > >> Is this still broken if you set up >> priorities for the emulator thread correctly and use PI mutexes in QEMU? > > I don't see why it would not, if you have to schedule the emulator > thread to process and inject I/O interrupts for example. Yes, you're right if it's interrupt injections. If it's unexpected disk accesses, you can just add a QEMU I/O thread on a different physical CPU. The same physical CPU can host I/O threads for different guests if you expect them to do little. I don't understand why is it correct to delay interrupt injection just because VCPU0 is running in a spinlock-protected region? I just cannot see the reason why it's safe and not a recipe for priority inversions. Paolo >> And if so, what is the cause of interruptions in the emulator thread >> and how are these interruptions causing the jitter? > > Interrupt injections. > >> Priorities and priority inheritance (or lack of them) is a _known_ >> issue. Jan was doing his KVM-RT things in 2009 and he was talking about >> priorities[1] back then. The effect of correct priorities is to _lower_ >> jitter, not to make it worse, and anyway certainly not worse than >> SCHED_NORMAL I/O thread. Once that's fixed, we can look at other problems. >> >> Paolo >> >> [1] http://static.lwn.net/images/conf/rtlws11/papers/proc/p18.pdf which >> also mentions pv scheduling