From: Rik van Riel <riel@redhat.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Mike Turquette <mturquette@linaro.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
kamalesh@linux.vnet.ibm.com,
Nicolas Pitre <nicolas.pitre@linaro.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Paul Turner <pjt@google.com>,
Benjamin Segall <bsegall@google.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Patch Tracking <patches@linaro.org>,
Tuukka Tikkanen <tuukka.tikkanen@linaro.org>,
Amit Kucheria <amit.kucheria@linaro.org>
Subject: Re: [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions
Date: Wed, 22 Oct 2014 22:42:46 -0400 [thread overview]
Message-ID: <54486B26.30703@redhat.com> (raw)
In-Reply-To: <1414030360.5228.12.camel@marge.simpson.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/22/2014 10:12 PM, Mike Galbraith wrote:
> 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?
It can, but IIRC that should cause the kvmclock data for that VCPU
to be regenerated, and the VCPU should be able to use that to figure
out that the frequency changed the next time it runs the scheduler
code on that VCPU.
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUSGsmAAoJEM553pKExN6DlhUH/RLmVoHmab2zfPgZfRXWD9PX
yKkx1tmoNPFAdp7l1xgz+fIVtp5I7gUnCo03r0x3JDL8dYiEfU1BfX1bs2WSresL
7q50DVLQe8VXIqgmu1INqzQSJGfF9yOW4Kgg2xHkNBoWUdt+3fjF9JSEMJFxOZOs
pFT85ITTs0zFIRDlwdEBEs0kRLEqh0JBeLx501RSC9VQ9OIZ3lp9O1BnawQ8WI0o
Qq8ODXFgy1BGUE+Ow+skP8MnQUyBgb6b+f0Q6AmK/Er6lzw8PMwNvnmYN14ruR3R
YkTjsyYxlYlzrx2IKZNWuYy5OXguRIslWi67fI0k/yE2WVHy/yXPbRErYQfM2o8=
=PeDr
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-10-23 2:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 6:07 [PATCH RFC 0/7] scheduler-driven cpu frequency scaling Mike Turquette
2014-10-22 6:07 ` [PATCH RFC 1/7] sched: Make energy awareness a sched feature Mike Turquette
2014-10-22 6:07 ` [PATCH RFC 2/7] sched: cfs: declare capacity_of in sched.h Mike Turquette
2014-10-22 6:07 ` [PATCH RFC 3/7] sched: fair: add usage_util_of helper Mike Turquette
2014-10-22 6:07 ` [PATCH RFC 4/7] cpufreq: add per-governor private data Mike Turquette
2014-10-22 6:26 ` Viresh Kumar
2014-10-22 6:35 ` Mike Turquette
2014-10-22 6:07 ` [PATCH RFC 5/7] sched: cfs: cpu frequency scaling arch functions Mike Turquette
2014-10-22 20:06 ` Rik van Riel
2014-10-22 23:20 ` Mike Turquette
2014-10-23 1:42 ` Rik van Riel
2014-10-23 2:12 ` Mike Galbraith
2014-10-23 2:42 ` Rik van Riel [this message]
2014-10-22 6:07 ` [PATCH RFC 6/7] sched: cfs: cpu frequency scaling based on task placement Mike Turquette
2014-10-23 4:03 ` Preeti U Murthy
2014-10-27 15:55 ` Peter Zijlstra
2014-10-27 17:42 ` Dietmar Eggemann
2014-11-27 10:46 ` Preeti U Murthy
2014-10-22 6:07 ` [PATCH RFC 7/7] sched: energy_model: simple cpu frequency scaling policy Mike Turquette
2014-10-27 19:43 ` Dietmar Eggemann
2014-10-28 14:27 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54486B26.30703@redhat.com \
--to=riel@redhat.com \
--cc=Morten.Rasmussen@arm.com \
--cc=amit.kucheria@linaro.org \
--cc=bsegall@google.com \
--cc=daniel.lezcano@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mturquette@linaro.org \
--cc=nicolas.pitre@linaro.org \
--cc=patches@linaro.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=preeti@linux.vnet.ibm.com \
--cc=tuukka.tikkanen@linaro.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).