On Wed, 2014-10-22 at 21:42 -0400, Rik van Riel wrote:
On 10/22/2014 07:20 PM, Mike Turquette wrote:
On Wed, Oct 22, 2014 at 1:06 PM, Rik van Riel riel@redhat.com wrote: On 10/22/2014 02:07 AM, Mike Turquette wrote:
arch_eval_cpu_freq and arch_scale_cpu_freq are added to allow the scheduler to evaluate if cpu frequency should change and to invoke that change from a safe context.
They are weakly defined arch functions that do nothing by default. A CPUfreq governor could use these functions to implement a frequency scaling policy based on updates to per-task statistics or updates to per-cpu utilization.
As discussed at Linux Plumbers Conference 2014, the goal will be to focus on a single cpu frequency scaling policy that works for everyone. That may mean that the weak arch functions definitions can be removed entirely and a single policy implements that logic for all architectures.
On virtual machines, we probably want to use both frequency and steal time to calculate the factor.
You mean for calculating desired cpu frequency on a virtual guest? Is that something we want to do?
A guest will be unable to set the cpu frequency, but it should know what the frequency is, so it can take the capacity of each CPU into account when doing things like load balancing.
Hm. Why does using vaporite freq/capacity/whatever make any sense, the silicon under the V(aporite)PU can/does change at the drop of a hat, no?
-Mike