Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752316AbdIVMkY (ORCPT ); Fri, 22 Sep 2017 08:40:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40836 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752125AbdIVMkW (ORCPT ); Fri, 22 Sep 2017 08:40:22 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 14F04C04B318 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mtosatti@redhat.com Date: Fri, 22 Sep 2017 09:40:05 -0300 From: Marcelo Tosatti To: Peter Zijlstra Cc: 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: <20170922124005.GA30393@amt.cnet> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170922123107.fjh2yfwnej73trim@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 22 Sep 2017 12:40:22 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1587 Lines: 50 On Fri, Sep 22, 2017 at 02:31:07PM +0200, Peter Zijlstra wrote: > On Fri, Sep 22, 2017 at 09:16:40AM -0300, Marcelo Tosatti wrote: > > On Fri, Sep 22, 2017 at 12:00:05PM +0200, Peter Zijlstra wrote: > > > On Thu, Sep 21, 2017 at 10:10:41PM -0300, Marcelo Tosatti wrote: > > > > When executing guest vcpu-0 with FIFO:1 priority, which is necessary > > > > to > > > > deal with the following situation: > > > > > > > > VCPU-0 (housekeeping VCPU) VCPU-1 (realtime VCPU) > > > > > > > > raw_spin_lock(A) > > > > interrupted, schedule task T-1 raw_spin_lock(A) (spin) > > > > > > > > raw_spin_unlock(A) > > > > > > > > Certain operations must interrupt guest vcpu-0 (see trace below). > > > > > > Those traces don't make any sense. All they include is kvm_exit and you > > > can't tell anything from that. > > > > Hi Peter, > > > > OK lets describe whats happening: > > > > With QEMU emulator thread and vcpu-0 sharing a physical CPU > > (which is a request from several NFV customers, to improve > > guest packing), the following occurs when the guest generates > > the following pattern: > > > > 1. submit IO. > > 2. busy spin. > > User-space spinning is a bad idea in general and terminally broken in > a RT setup. Sounds like you need to go fix qemu to not suck. Are you arguing its invalid for the following application to execute on housekeeping vcpu of a realtime system: void main(void) { submit_IO(); do { computation(); } while (!interrupted()); } Really? Replace "busy spin" by "useful computation until interrupted".