From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 0/3] KVM CPU frequency change hypercalls Date: Fri, 24 Feb 2017 08:50:00 -0300 Message-ID: <20170224114958.GA28618@amt.cnet> References: <20170202174755.946578704@redhat.com> <20170203164349.GA5582@potion> <20170203181405.GA1869@amt.cnet> <20170203190930.GD15128@potion> <5db0e1a1-2eaf-fe77-3e15-7b2ef842d255@redhat.com> <20170223231923.GB23631@amt.cnet> <5310a7a1-3c3b-7b19-4f2d-6f7919c7b560@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Radim Krcmar , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Viresh Kumar To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:50186 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbdBXLu1 (ORCPT ); Fri, 24 Feb 2017 06:50:27 -0500 Content-Disposition: inline In-Reply-To: <5310a7a1-3c3b-7b19-4f2d-6f7919c7b560@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 24, 2017 at 10:18:59AM +0100, Paolo Bonzini wrote: > > > On 24/02/2017 00:19, Marcelo Tosatti wrote: > >>> i.e. our feature implies userspace tasks pinned to isolated vCPUs. > > This is how cpufreq-userspace works: > > > > 2.2 Governor > > ------------ > > > > On all other cpufreq implementations, these boundaries still need to > > be set. Then, a "governor" must be selected. Such a "governor" decides > > what speed the processor shall run within the boundaries. One such > > "governor" is the "userspace" governor. This one allows the user - or > > a yet-to-implement userspace program - to decide what specific speed > > the processor shall run at. > > The userspace program sets a policy for the whole system. No, its per cpu. > >> That's bad. This feature is broken by design unless it does proper > >> save/restore across preemption. > > > > Whats the current usecase, or forseeable future usecase, for save/restore > > across preemption again? (which would validate the broken by design > > claim). > > Stop a guest that is using cpufreq, start a guest that is not using it. > The second guest's performance now depends on the state that the first > guest left in cpufreq. Nothing forbids the host to implement switching with the current hypercall interface: all you need is a scheduler hook. > I think this is abusing the userspace governor. Unfortunately cpufreq > governors cannot be stacked. > > Paolo This is a special usecase where only the app in the guest knows whats the most appropriate frequency at a given time. This is what cpufreq-userspace is supposed to allow userspace to do, but in this case "userspace" is the guest, so i don't see this as an abuse at all. Timeshared setups are by definition not deterministic: your task A could be interrupted by another task B with results similar to a lower frequency being set. So saying that: "Our frequency scaling interface goes against the idea -- guest kernel cannot schedule multiple userspaces on the same vCPU, because they could conflict by overriding frequency." Assumes that, in a timeshared system, an application is guaranteed a particular frequency. But that does not make sense: its a timeshared system in the first place, there is no determinism regarding execution time. Moreover, there is no notion of "per-task CPU frequency" in Linux (there could be, this whole governor business with user being responsible for setting up the governor is pretty sucky IMO).