From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751821AbdIVBIj (ORCPT ); Thu, 21 Sep 2017 21:08:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39552 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751779AbdIVBIi (ORCPT ); Thu, 21 Sep 2017 21:08:38 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CE14A3680B Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=mtosatti@redhat.com Date: Thu, 21 Sep 2017 22:08:13 -0300 From: Marcelo Tosatti To: Paolo Bonzini Cc: Konrad Rzeszutek Wilk , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [patch 2/3] KVM: x86: KVM_HC_RT_PRIO hypercall (host-side) Message-ID: <20170922010811.GA20133@amt.cnet> References: <20170921113835.031375194@redhat.com> <20170921114039.364395490@redhat.com> <20170921133212.GN26248@char.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.30]); Fri, 22 Sep 2017 01:08:37 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 21, 2017 at 03:49:33PM +0200, Paolo Bonzini wrote: > On 21/09/2017 15:32, Konrad Rzeszutek Wilk wrote: > > So the guest can change the scheduling decisions at the host level? > > And the host HAS to follow it? There is no policy override for the > > host to say - nah, not going to do it? In that case the host should not even configure the guest with this option (this is QEMU's 'enable-rt-fifo-hc' option). > > Also wouldn't the guest want to always be at SCHED_FIFO? [I am thinking > > of a guest admin who wants all the CPU resources he can get] No. Because in the following code, executed by the housekeeping vCPU running at constant SCHED_FIFO priority: 1. Start disk I/O. 2. busy spin With the emulator thread sharing the same pCPU with the housekeeping vCPU, the emulator thread (which runs at SCHED_NORMAL), will never be scheduled in in place of the vcpu thread at SCHED_FIFO. This causes a hang. > Yeah, I do not understand why there should be a housekeeping VCPU that > is running at SCHED_NORMAL. If it hurts, don't do it... Hope explanation above makes sense (in fact, it was you who pointed out SCHED_FIFO should not be constant on the housekeeping vCPU, when sharing pCPU with emulator thread at SCHED_NORMAL).