From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [patch 0/3] KVM CPU frequency change hypercalls (resend) Date: Wed, 15 Mar 2017 15:30:00 -0300 Message-ID: <20170315182957.GA7981@amt.cnet> References: <20170301150423.915563751@redhat.com> <20170302135940.GA19287@amt.cnet> <20170314232748.GA15962@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, linux-pm@lists.linux-foundation.org, Radim Krcmar , "Rafael J. Wysocki" , Viresh Kumar To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41150 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbdCQVia (ORCPT ); Fri, 17 Mar 2017 17:38:30 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Mar 15, 2017 at 09:23:10AM +0100, Paolo Bonzini wrote: > > > On 15/03/2017 00:27, Marcelo Tosatti wrote: > >> So, the question then is how to design the hypervisor so that these NFV > >> virtual machines can play with cpufreq, but there are no adverse > >> indefinite effects. > > Ok, we can modify the cpufreq cgroups patch, to, from the hypercalls > > set the: > > > > "The first three patches of this series introduces > > capacity_{min,max} tracking > > in the core scheduler, as an extension of the CPU controller." > > > > capacity_min == capacity_max values (which forces the CPU to run > > at that frequency, given there are no other tasks requesting > > frequency information on that CPU). > > > > This is good enough DPDK. > > So this sounds like a plan? Yes, trying that now... > > >> One possibility is to have some kind of per-task > >> cpufreq. Another is to do everything in userspace with virtual ACPI > >> P-states and the userspace governor in the VM. > > > > Virtual ACPI P-state, that is an option. But why not make it > > in-kernel, the exit to userspace can be a significant > > fraction of the total if the frequency change time is small (say, 10us > > freq change and 5us for userspace exit). > > The advantage of doing it in userspace is that the sysfs chmod is a > clear way to say "this VM should have the privilege of setting cpufreq. > In effect, userspace's file descriptor for the sysfs files represents > the capability to set cpufreq for the VM. You can even pass the file > descriptor with SCM_RIGHTS if you wish to do so. > > But of course that's only needed if the frequency change is global per > physical CPU. if the CPU controller gains the ability to do per-task > frequency switching, that's even better for KVM. Then the hypercalls > are just fine and we can have a KVM-specific cpufreq controller. > > Paolo I see, thanks.