On 01/03/2017 16:04, Marcelo Tosatti wrote: > > 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. I would like to understand the intended usecase of cpufreq-userspace. My understanding is that you would have a daemon handling a systemwide policy; examples are the historical (and now obsolete) users such as cpufreqd, cpudyn, powernowd, or cpuspeed. The user alternatively can play the role of the daemon by writing to sysfs, but I've never seen userspace tasks talking to cpufreq-userspace to set their own running frequency. Apparently DPDK does that, and I would like to know the opinion of the linux-pm folks; one obvious downside is that any application that you run after DPDK will have its CPU frequency hardcoded to something that is not appropriate. This might be acceptable for DPDK, but it is worse for KVM which tries to provide isolation to its vCPU tasks. Here are two possibilities that I could think of: 1) Introduce a mechanism that allows a task to override the governor's choice of CPU frequency. This could be a ioctl, a prctl, a cgroup-based mechanism or whatever else. As Marcelo pointed out in the original kvm@ thread, the latency and overhead of switching frequencies make it impractical to associate a desired CPU frequency with a task, because multiple tasks could be requesting a given frequency. One possibility could be to treat the per-task CPU frequency as advisory and only obey it in restricted cases---for example only if nohz_full is in effect. 2) In the KVM API, the userspace program that enables the hypercalls must pass writable file descriptors for the physical CPU's scaling_setspeed files. These file descriptors act as a "proof" that the userspace program could anyway modify the speed. However, this is just a very handwavy description, and in particular I haven't thought very much of how to handle either task migration or CPU hotplug. Thanks in advance to anyone contributing to the discussions. Paolo
