NOTE: resending because of comments regarding that the cpufreq-userspace scheme is bad design and something different should be done. The requirements that i've came up with are below. Code comments of v1 are being addressed, not necessary to make them again. Paolo: please comment on your objections and what should be done instead. Note the case "multiple vcpus on a given pcpu" is not part of the usecase in question. =========================================================== Implement KVM hypercalls for the guest to issue frequency changes. Current situation with DPDK and frequency changes is as follows: An algorithm in the guest decides when to increase/decrease frequency based on the queue length of the device. On the host, a power manager daemon is used to listen for frequency change requests (on another core) and issue these requests. However frequency changes are performance sensitive events because: On a change from low load condition to max load condition, the frequency should be raised as soon as possible. Sending a virtio-serial notification to another pCPU, waiting for that pCPU to initiate an IPI to the requestor pCPU to change frequency, is slower and more cache costly than a direct hypercall to host to switch the frequency. If the pCPU where the power manager daemon is running is not busy spinning on requests from the isolated DPDK vcpus, there is also the cost of HLT wakeup for that pCPU. Moreover, the daemon serves multiple VMs, meaning that the scheme is subject to additional delays from queueing of power change requests from VMs. A direct hypercall from userspace is the fastest most direct method for the guest to change frequency and does not suffer from the issues above. The usage scenario for this hypercalls is for pinned vCPUs <-> pCPUs.
