From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH 1/3] KVM: Don't enable MWAIT in guest by default Date: Tue, 28 Nov 2017 16:00:29 +0200 Message-ID: <20171128154912-mutt-send-email-mst@kernel.org> References: <1511615373-32615-1-git-send-email-jschoenh@amazon.de> <1511615373-32615-2-git-send-email-jschoenh@amazon.de> <20171127224620-mutt-send-email-mst@kernel.org> <05cfee2a-d4be-c196-b4a3-46a058f66773@amazon.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel , KarimAllah Ahmed , kvm@vger.kernel.org To: Jan =?iso-8859-1?Q?H=2E_Sch=F6nherr?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43902 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751936AbdK1OAc (ORCPT ); Tue, 28 Nov 2017 09:00:32 -0500 Content-Disposition: inline In-Reply-To: <05cfee2a-d4be-c196-b4a3-46a058f66773@amazon.de> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Nov 27, 2017 at 11:36:11PM +0100, Jan H. Schönherr wrote: > On 11/27/2017 09:46 PM, Michael S. Tsirkin wrote: > > On Sat, Nov 25, 2017 at 02:09:31PM +0100, Jan H. Schönherr wrote: > >> Allowing a guest to execute MWAIT without interception enables a guest > >> to put a (physical) CPU into a power saving state, where it takes > >> longer to return from than what may be desired by the host. > >> > >> Don't give a guest that power over a host by default. (Especially, > >> since nothing prevents a guest from using MWAIT even when it is not > >> advertised via CPUID.) > >> > >> This restores the behavior from before Linux 4.12 commit 668fffa3f838 > >> ("kvm: better MWAIT emulation for guests") but keeps the option to > >> enable MWAIT in guest for individual VMs. > > > > As others pointed out, an interrupt will wake up the host CPU anyway. > > > > Given that, what's the actual motivation here? > > The CPU will wake up, but it will take time depending which C-state the > guest requested and achieved to enter. > > Since Linux 4.11 and 4.14 the menu and ladder cpuidle governors, respectively, > allow setting a per CPU wakeup latency requirement -- see, eg, commit c523c68da211 > ("cpuidle: ladder: Add per CPU PM QoS resume latency support"). Allowing a guest > to execute MWAIT without moderation will bypass that functionality. > > Thus, while MWAIT-in-guest is a great thing to have when there are dedicated > CPUs, it is less so, when the CPUs still have to do other activities. > > Regards > Jan I see. And the example given there is a CPU running real time applications. If you do another version, it might be helpful to add this info. E.g. "... than desired by the host - e.g. when the same CPU is running another real time applications". I wonder how well does it work to mix real time apps and VMs on the same CPU. -- MST