Re: [patch 0/3] KVM CPU frequency change hypercalls (resend)

[Marcelo Tosatti <mtosatti@redhat.com>]

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.