Messages in this thread |  | | Subject | Re: [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions | From | Mike Galbraith <> | Date | Thu, 23 Oct 2014 04:12:40 +0200 |
| |
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
|  |