Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752549AbdI2RF4 (ORCPT ); Fri, 29 Sep 2017 13:05:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37550 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752388AbdI2RFp (ORCPT ); Fri, 29 Sep 2017 13:05:45 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E2779A70B Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.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: <855950672.7912001.1506258344142.JavaMail.zimbra@redhat.com> <20170925025751.GB30813@amt.cnet> <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> From: Paolo Bonzini Message-ID: Date: Fri, 29 Sep 2017 19:05:41 +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: <20170929164006.GC29391@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.29]); Fri, 29 Sep 2017 17:05:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1433 Lines: 31 On 29/09/2017 18:40, Marcelo Tosatti wrote: >> If you know you have this kind disk workload, you must use virtio-blk or >> virtio-scsi with iothreads and place the iothreads on their own physical >> CPUs. >> >> Among "run arbitrary workloads", "run real-time workloads", "pack stuff >> into as few physical CPUs as possible", you can only pick two. > > 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? Is this still broken if you set up priorities for the emulator thread correctly and use PI mutexes in QEMU? And if so, what is the cause of interruptions in the emulator thread and how are these interruptions causing the jitter? 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