On 10/12/2015 06:55 AM, Vincent Guittot wrote:
>> For the RT story, are you thinking to use rq->rt_avg in some way?
>
> Yes that was my goal but the deadline is also accounted in rq->rt_avg
> which is then used in scale_rt_capacity. I was planning to remove the
> deadline class from rq->rt_avg and to use the per cpu deadline
> bandwidth in scale_rt_capacity instead
If the deadline contribution to rq->rt_avg is left in place, can RT and
deadline both be accounted for via that one mechanism for the purposes
of sched-dvfs?
I'm not sure how the accuracy/behavior of the deadline accounting to
rq->rt_avg differs from the forthcoming patchset Juri mentioned, but if
it's not as good, perhaps the mechanisms could be combined so that
rt_avg (and by extension the per-CPU capacity adjustments in CFS)
benefit as well.
Hi all,
Below are some thoughts and questions after reviewed EAS's energy model; my
purpose is want to get clear the energy model from user's perspective, so
below question will _ONLY_ focus on the model and not dig into the
implementation.
This email is related long, but i think if use formulas, we can easily
get the same page; So i lists the energy model's formulas, then based
on them i try to match with TC2's power data and bring up some questions.
Look forward to your suggestions and comments.
* Basic Energy and Power Calculation Formulas
From the doc Documentation/scheduler/sched-energy.txt, we can get to know
the energy can be calculated with:
Energy [j] = Power [w] * Time [s] (F.1)
So let's assume there have one piece of code, which has fixed instruction
numbers will be executed on CPU, the execution duration is depend on CPU's
pipeline and CPU's frequency. So can convert F.1 to F.2:
Code [instructions]
Energy [j] = Power [w] * ------------------------------
(Inst Per Cycle) * Frequency
Code [instructions]
= Power [w] * ------------------------------ (F.2)
MIPS(f)
`-> 'f' is factor of frequency
Because MIPS(f) can be normalize as the CPU's capacity corresponding to
OPP, so we can simply convert from F.2 to F.3:
Code [instructions]
Energy [j] = Power [w] * ------------------------------ (F.3)
CPU_Capacity(f)
If breakdown Power[w], we can split it into two parts: static leakage, and
dynamic leakage:
Power [w] = Ps [w] + Pd [w] (F.4)
Static power leakage can be calculated with below formula:
Ps [w] = i * V [v] (F.5)
`-> 'i' is coefficient for according to silicon's process
V [v] is voltage according to OPP
Dynamic power leakage can be calculated with below formula:
Pd [w] = b * V [v] * V [v] * frequency (F.6)
`-> 'b' is coefficient for according to silicon's process
V [v] is voltage according to OPP
Here have two special cases, if the island's clock is gated, then
Pd [w] = 0, So:
Power [w] = Ps [w] (F.7)
If the island is powered off, then
Ps [w] = 0, Pd [w] = 0; So:
Power [w] = 0 (F.8)
So energy can be calculated as (come from F.3 and F.4):
Code [instructions]
Energy [j] = (Ps [w] + Pd [w]) * ---------------------- (F.9)
CPU_Capacity(f)
* Formulas for duty cycle
We separate the logic (cluster or CPU) into two states: P-state and C-state,
for P-state and C-state they have different power data, this is because
after the logic enter C-state, it will be clock gating or powered off. So if
we expand the time axis for relative long time, we need calculate CPU's
utilization percentage (for CPU is full running, util = 100%). Let's
simplize the ratio between "Code [instructions]" and "CPU_Capactity(f)" as
the utilization, So the energy calculation can be depicted as:
Code [instructions]
Util(f) = -------------------------- (F.10)
CPU_Capacity(f)
Energy [j] = Power_Pstate [w] * Util(f)
+ Power_Cstate [w] * (1 - Util(f)) (F.11)
(F.12)
Energy [j] = Sum(i=0..MAX_OPP)(Power_Pstate [w](i) * Util_OPP(i))
+ Sum(i=0..MAX_IDL)(Power_Cstate [w](i) * Util_IDL(i))
Sum(i=0..MAX_OPP)Util_OPP(i) + Sum(i..MAX_IDLE)Util_IDL(i) = 1
* Formulas for clusters
(F.13)
Energy [j] = Energy_cluster [j]
+ Sum(i=0..MAX_CPU_PER_CLUSTER)Energy_cpu(i) [j]
(F.14)
Energy_cluster [j]
= Sum(i=0..MAX_OPP)(Power_Pstate [w](i) * Util_OPP(i))
+ Sum(i=WFI, ClusterOff)(Power_Cstate [w](i) * Util_IDL(i))
(F.15)
Energy_cpu [j]
= Sum(i=0..MAX_OPP)(Power_Pstate [w](i) * Util_OPP(i))
+ Sum(i=WFI, CPUOff)(Power_Cstate [w](i) * Util_IDL(i))
* Thoughts and Questions
- Let's summary EAS's energy model as below:
CPU::capacity_state::power : CPU's power [w] for specific OPP
Power(OPP) = Ps [w] + Pd [w]
CPU::idle_state::power : CPU's power [w] for specific idle state
Power(IDLE_WFI) = Ps [w]
Power(IDLE_CPUOff) = 0
CPU's IDLE_WFI means: CPU is clock gating, so has static leakage but
don't include dynamic leakage.
CLUSTER::capacity_state::power : Cluster's power [w] for specific OPP
Power(OPP) = Ps [w] + Pd [w]
CLUSTER::idle_state::power : CPU's power [w] for specific idle state
Power(IDLE_WFI) = Ps [w] + Pd [w]
Power(IDLE_CLSOff) = 0
Cluster's IDLE_WFI is quite special, means all CPUs in cluster have been
powered off, but cluster's logic (L2$ and SCU, etc) is powered on and clock
is enabled, so it includes cluster level's static power and dynamic power.
Are these formulas matching the original design?
- TC2's data for cluster's sleep:
static struct idle_state idle_states_cluster_a7[] = {
{ .power = 25 }, /* WFI */
{ .power = 10 }, /* cluster-sleep-l */
};
static struct idle_state idle_states_cluster_a15[] = {
{ .power = 70 }, /* WFI */
{ .power = 25 }, /* cluster-sleep-b */
};
For cluster level's sleep, the clock is gating and domain is powered off,
so the dynamic leakage and static leakge should be zero, right?
- TC2's data for CPU's idle state:
static struct idle_state idle_states_core_a7[] = {
{ .power = 0 }, /* WFI */
};
static struct idle_state idle_states_core_a15[] = {
{ .power = 0 }, /* WFI */
};
CPU has two idle state, one is 'WFI' and another is 'C2'; For 'WFI' state,
the power will not be zero, this is because 'WFI' state means internal
clock gating, so according to F.7, there should have static leakage.
BTW, for TC2, there have no corresponding idle state for 'C2', this is
weird. Could you confirm it has been delibrately removed?
- TC2's data for P-state:
static struct capacity_state cap_states_cluster_a7[] = {
/* Cluster only power */
{ .cap = 150, .power = 2967, }, /* 350 MHz */
[...]
};
static struct capacity_state cap_states_core_a7[] = {
/* Power per cpu */
{ .cap = 150, .power = 187, }, /* 350 MHz */
[...]
};
From previous experience, the CPU level's power leakage is very higher
than cluster level's leakage. For example, for CA7, if only power on cluster
(all CPUs in cluster are powered off), the power delta is ~10mA@156MHz; if
power on one CPUs, the power delta is about 30mA@156MHz. I also checked the
data for CA53, it has similar result.
So this is confilict with TC2's power data, you can see the cluster
level's power leakage is quite high (almost 15 times than CPU level). This
means almostly we cannot get much benefit from CPU level's low power
state, due cluster level will contribute most of power consumption. This
is not make sense.
- From formula F.4, we can combine power with static leakage and dynamic
leakage; IPA also used static/dynamic leakage to depict energy model. But
EAS uses another way, which provide the power data according to every OPP
and idle state. So that means on one platform, we need provide two kinds
of power data.
IMHO, i think the static and dynamic leakage is more simple; because
usually we will use (mW/MHz) to describe the power efficiency for specific
CPU, though (mW/MHz) cannot very accurately for power consumption if the
voltage has been changed (See formula F.6, usually the voltage will be
increased at higher frequency). But if we use mW/MHz, maybe we can
calculate with very simple way for we can just only use it to mulitplate
with frequency to get dynamic power.
So we only need provide below parameters:
P-state: static leakage, power efficiency (mW/MHz), capacity (DMIPS/MHz);
C-state: static leakage, power efficiency (mW/MHz);
What's the thoughts for unify the energy model?
Thanks,
Leo Yan
Hi eas-dev,
as pre-announced by Morten on that ML, last week we posted on LKML
an RFC introducing SchedTune, a proposal for a central tuning knob.
The current posting addresses DVFS biasing only. There will be a
follow up posting to deal with task placement via integration with EAS
as the upstream discussions move along.
The full cover letter can be found here:
http://www.kernelhub.org/?msg=819910&p=2
For your convenience the patch set is available here:
git://www.linux-arm.com/linux-power eas/stune/rfcv1
Cheers Patrick
--
#include <best/regards.h>
Patrick Bellasi
Hi eas-dev,
In case you don't follow LKML, we have posted RFCv5 of the EAS patch set
for review and comments. The main addition in this posting is
scheduler-driven DVFS along with a number of smaller fixes and
improvements. The full cover letter can be found here:
https://lkml.org/lkml/2015/7/7/754
For your convenience the patch set is available here:
http://www.linux-arm.org/git?p=linux-power.git
branch: energy_model_rfc_v5
Additional patches introducing a central tuning knob that influences
both task placement and DVFS will be posted later for discussion.
Thanks,
Morten
Hi Alex,
In 4.1-rc1, several patches (see 36ee28e4 onwards) related to cpu
capacity consolidation were merged.
It would be a good idea to refresh the eas-backport tree so that these
patches are cherry-picked directly from mainline into
stable/sched-upstream branch and their equivalent versions in
stable/sched-core are removed.
Regards,
Amit
This series implements an event-driven cpufreq governor that scales cpu
frequency as a function of cfs runqueue utilization. The intent of this RFC is
to get some discussion going about how the scheduler can become the policy
engine for selecting cpu frequency, what limitations exist and what design do
we want to take to get to a solution.
This series depends on having frequency-invariant representations for load.
This requires Vincent's recently merged cpu capacity rework patches, as well as
a new patch from Morten included here. Morten's patch will likely make an
appearance in his energy aware scheduling v4 series.
Thanks to Juri Lelli <juri.lelli(a)arm.com> for contributing to the development
of the governor.
A git branch with these patches can be pulled from here:
https://git.linaro.org/people/mike.turquette/linux.git sched-freq
Smoke testing has been done on an OMAP4 Pandaboard and an Exynos 5800
Chromebook2. Extensive benchmarking and regression testing has not yet been
done. Before sinking too much time into extensive testing I'd like to get
feedback on the general design.
Michael Turquette (3):
sched: sched feature for cpu frequency selection
sched: export get_cpu_usage & capacity_orig_of
sched: cpufreq_sched_cfs: PELT-based cpu frequency scaling
Morten Rasmussen (1):
arm: Frequency invariant scheduler load-tracking support
arch/arm/include/asm/topology.h | 7 +
arch/arm/kernel/smp.c | 53 ++++++-
arch/arm/kernel/topology.c | 17 +++
drivers/cpufreq/Kconfig | 24 +++
include/linux/cpufreq.h | 3 +
kernel/sched/Makefile | 1 +
kernel/sched/cpufreq_sched_cfs.c | 314 +++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 20 ++-
kernel/sched/features.h | 6 +
kernel/sched/sched.h | 9 ++
10 files changed, 450 insertions(+), 4 deletions(-)
create mode 100644 kernel/sched/cpufreq_sched_cfs.c
--
1.9.1
This series implements an event-driven cpufreq governor that scales cpu
frequency as a function of cfs runqueue utilization. The intent of this RFC is
to get some discussion going about how the scheduler can become the policy
engine for selecting cpu frequency, what limitations exist and what design do
we want to take to get to a solution.
This work is a different take on the patches I posted in November:
http://lkml.kernel.org/r/<1413958051-7103-1-git-send-email-mturquette(a)linaro.org>
This series depends on having frequency-invariant representations for load.
This requires Vincent's recently merged cpu capacity rework patches, as well as
a new patch from Morten included here. Morten's patch will likely make an
appearance in his energy aware scheduling v4 series.
Thanks to Juri Lelli <juri.lelli(a)arm.com> for contributing to the development
of the governor.
A git branch with these patches can be pulled from here:
https://git.linaro.org/people/mike.turquette/linux.git sched-freq
Smoke testing has been done on an OMAP4 Pandaboard and an Exynos 5800
Chromebook2. Extensive benchmarking and regression testing has not yet been
done. Before sinking too much time into extensive testing I'd like to get
feedback on the general design.
Michael Turquette (3):
sched: sched feature for cpu frequency selection
sched: export get_cpu_usage & capacity_orig_of
sched: cpufreq_sched_cfs: PELT-based cpu frequency scaling
Morten Rasmussen (1):
arm: Frequency invariant scheduler load-tracking support
arch/arm/include/asm/topology.h | 7 +
arch/arm/kernel/smp.c | 53 ++++++-
arch/arm/kernel/topology.c | 17 +++
drivers/cpufreq/Kconfig | 24 ++++
include/linux/cpufreq.h | 3 +
kernel/sched/Makefile | 1 +
kernel/sched/cpufreq_cfs.c | 311 ++++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 48 +++----
kernel/sched/features.h | 6 +
kernel/sched/sched.h | 39 +++++
10 files changed, 475 insertions(+), 34 deletions(-)
create mode 100644 kernel/sched/cpufreq_cfs.c
--
1.9.1
Hi Alex,
Robin asked me to share with you the patches that I found having conflicts on
the Juno LSK integration branch. It would be helpful to know your feelings
about them (are they fundamental? can they be dropped? etc.). The aim here
is to understand if we can eventually come up with a sched-upstream branch
that is more easily applicable on top of the Juno integration branch:
http://git.linaro.org/landing-teams/working/arm/kernel.git integration-lsk-3.10-juno-android
I'll try to give you a list of patches that I had to remove or revert from
sched-upstream when trying to build a branch that supports Juno and has EASv3
on top (so that we could test it on Android). I'll also add comments about
patches that I'm more familiar with. Please be aware that I had to come up
with this in quite a hurry, as we wanted to show EAS results coming from
Juno at the last Connect. This means that the rationale for deciding to keep
or drop a patch in the branch was merely "drop everything that seems to have
non trivial conflicts". At the end I was fairly happy with the behaviours,
but this doesn't necessarily mean that we still not need some of what I
dropped.
080bdd1 exit.c: unexport __set_special_pids()
cdba026 ptrace: revert "Prepare to fix racy accesses on task breakpoints"
73bcb2e mm: remove free_area_cache
802d8c2 ptrace/x86: revert "hw_breakpoints: Fix racy access to ptrace breakpoints"
6472001 ptrace/arm: revert "hw_breakpoints: Fix racy access to ptrace breakpoints"
f0a709a sched: Add new scheduler syscalls to support an extended scheduling parameters ABI
631db36 sched/core: Fix htmldocs warnings
4f89001 sched: Preserve the nice level over sched_setscheduler() and sched_setparam() calls
c9d415b sched: Fix up scheduler syscall LTP fails
0525ffc sched: Fix up attr::sched_priority warning
b62aed3 sched: Move SCHED_RESET_ON_FORK into attr::sched_flags
7d214b1 sched: Fix __sched_setscheduler() nice test
9db9c75 sched: Fix information leak in sys_sched_getattr()
10d4f89 sched: Add 'flags' argument to sched_{set,get}attr() syscalls
as this preceding set comes with the (or are subsequent fixes of)
the SCHED_DEADLINE patchset, I think we could just ignore them for now
02fee98 ARM: introduce common set_auxcr/get_auxcr functions
6a4f9e7 sched: Implement task_nice() as static inline function
this preceding patch is maybe not a crucial fix?
6261e04 sched: Adjust p->sched_reset_on_fork when nothing else changes
33e8006 sched: Replace hardcoding of -20 and 19 with MIN_NICE and MAX_NICE
this two preceding patches depend on 6a4f9e7
15bfe13 arm64: use common reboot infrastructure
52cefcb arm64: Fix definition of arm_pm_restart to match the declaration
8c7b4f7 arm64: kernel: add CPU idle call
e1bf4b0 time: Change the return type of clockevents_notify() to integer
ff5e6b8 tracing: Do not do anything special with tracepoint_string when tracing is disabled
2e576ce tracepoint: add generic tracepoint definitions for IPI tracing
5174675 ARM: 7872/1: Support arch_irq_work_raise() via self IPIs
128647d ARM: SMP: basic IPI triggered completion support
eccd85f ARM: add IPI tracepoints
5be433d arm64: enable generic clockevent broadcast
e947689 arm64: Support arch_irq_work_raise() via self IPIs
5716acb ARM64: add IPI tracepoints
I then had to revert the following patches.
db9cfbf sched/idle: Optimize try-to-wake-up IPI
50299a0 sched/idle: Avoid spurious wakeup IPIs
7f219d1 sched, trace: Add a tracepoint for IPI-less remote wakeups
95ec016 sched/idle: Simplify wake_up_idle_cpu()
And finally apply the attached patches to make the branch compile.
Please don't hesitate to ask for more information, as I understand
that all this might be quite confusing :).
Best,
- Juri
This series implements an event-driven cpufreq governor that scales cpu
frequency as a function of cfs runqueue utilization. The intent of this RFC is
to get some discussion going about how the scheduler can become the policy
engine for selecting cpu frequency, what limitations exist and what design do
we want to take to get to a solution.
This series depends on having frequency-invariant representations for load.
This requires Vincent's recently merged cpu capacity rework patches, as well as
two patches posted by Morten in his energy aware scheduling v3 series. The
latter two patches are included in this series for posterity, but discussion
around them probably belongs in the v3 eas series or the forthcoming v4 series.
Thanks to Juri Lelli <juri.lelli(a)arm.com> for contributing to the development
of the governor.
A git branch with these patches can be pulled from here:
https://git.linaro.org/people/mike.turquette/linux.git sched-freq
Smoke testing has been done on an OMAP4 Pandaboard and an Exynos 5800
Chromebook2.
---8<---
eas-dev,
Please let me know what you think of this series, including code as well as
cover letter and commitlog text. I was not able to finish the irq_work
additions to the governor in time for me to submit this tonight (these changes
remove the periodic behavior of calling cap_gov_kick_thread from
run_rebalance_domains). I'll focus on the irq_work stuff tomorrow and post an
addenedum to this series asap.
I have not done any benchmark testing with this series. That is also on my todo
list for this week and any help there would be appreciated.
Freedom & Howard, if you are bored and feel like measuring power across some
benchmarks on your non-buggy EVBs then please do. I can only measure power on
the A53s right now which limits me to a single cluster with two cores.
Regards,
Mike
Michael Turquette (4):
sched: sched feature for cpu frequency selection
cpufreq: add per-governor private data
sched: export get_cpu_usage in sched.h
sched: cap_gov: PELT-based cpu frequency scaling
Morten Rasmussen (2):
cpufreq: Architecture specific callback for frequency changes
arm: Frequency invariant scheduler load-tracking support
arch/arm/include/asm/topology.h | 4 +
arch/arm/kernel/topology.c | 41 +++++
drivers/cpufreq/Kconfig | 22 +++
drivers/cpufreq/cpufreq.c | 13 +-
include/linux/cpufreq.h | 6 +
kernel/sched/Makefile | 1 +
kernel/sched/cap_gov.c | 361 ++++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 26 ++-
kernel/sched/features.h | 6 +
kernel/sched/sched.h | 10 ++
10 files changed, 488 insertions(+), 2 deletions(-)
create mode 100644 kernel/sched/cap_gov.c
--
1.9.1
Hi,
It seems that eas-dev is stripping people on cc in certain cases. When I
receive copies of my own replies the topic is prefixed with "[Eas-dev]"
and the cc list only contains eas-dev itself.
Is that a deliberate choice? IMHO it would be better to keep the cc list
in case you want to reply to your own messages.
It also looks like people are removed from to/cc when others reply to
messages received through the list (not in to/cc).
Thanks,
Morten
Hi Juri & Morten,
Thanks for taking the quick call today. Here are some of the patches
from the EAS V3 which I think are outstanding dependencies for
sched-freq to be posted on LKML:
#4 "sched: Make sched entity usage tracking frequency-invariant"
#11 "sched: Make load tracking frequency scale-invariant"
#13 "cpufreq: Architecture specific callback for frequency changes"
Vincent's fix for setting current freq (should be rolled into #13 above):
https://git.linaro.org/people/vincent.guittot/kernel.git/commitdiff/3ac2b6a…
#14 "arm: Frequency invariant scheduler load-tracking support"
Let me know what you think.
Regards,
Mike
FYI, this week ARM opensourced the Workload Automation suite that is useful for EAS evaluation
License is Apache ver 2.0
https://github.com/ARM-software/workload-automation
(see README for details)
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hi Amit,
since I've got a backport of EASv3 and I'd like to share this
with all, can you please give me an update about the EAS
backport tree maintenance bits we agreed upon.
Thanks a lot,
- Juri
This event has been changed.
Title: sched-dvfs design discussion
Link to Google HO is in the meeting details. If that doesn't work for
everyone then we can use some teleconf method.
The main purpose of the call is to discuss:
1) locking issues around get_cpu_usage
2) the polling nature of the current governor code and its implications
3) designing for the non-blocking DVFS case and for unification of task
placement and frequency selection decisions
When: Wed 2015-03-18 9:30am - 10:30am Pacific Time (changed)
Video call: https://plus.google.com/hangouts/_/linaro.org/sched-dvfs
<https://plus.google.com/hangouts/_/linaro.org/sched-dvfs?hceid=bWlrZS50dXJx…>
Calendar: Mike Turquette
Who:
* Mike Turquette - organizer
* Morten Rasmussen
* Amit Kucheria
* eas-dev(a)lists.linaro.org
* Vincent Guittot
* Juri Lelli
* Daniel Lezcano
* dietmar.eggemann(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=a2s1amRldW4zY28yMTdlY…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
eas-dev(a)lists.linaro.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Hi all,
as agreed with Mike, I'm posting here his sched-dvfs patchset [1] plus
my EAS bindings to make it use the energy model. This is meant to re-start
discussion on the attempt to drive dvfs directly from the scheduler.
This patchset is based on 4.0-rc2 + EASv3 [2].
Mike is already working on a slightly different, more "reactive", approach.
The way we can use EAS infrastructure shouldn't change much anyway, so this
works also as a first example of such thing. The core of my little delta
resides in the possibility to read the energy tables to get freq and uarch
invariance in the new governor (4/6) and the use of get_cpu_usage() to
get the utilization signal from the scheduler (that I squashed in 02/06
together with some little fixes).
Best,
- Juri
[1] https://lkml.org/lkml/2014/10/22/21
[2] https://lkml.org/lkml/2015/2/4/537
Juri Lelli (3):
sched/energy_model: use EAS energy model
sched/energy_model: bound kthreads to run on related_cpus
sched/energy_model: fix spurious kicks
Michael Turquette (1):
sched: cfs: cpu frequency scaling based on task placement
Mike Turquette (2):
cpufreq: add per-governor private data
sched: energy_model: simple cpu frequency scaling policy
drivers/cpufreq/Kconfig | 21 +++
include/linux/cpufreq.h | 6 +
kernel/sched/Makefile | 1 +
kernel/sched/energy_model.c | 364 ++++++++++++++++++++++++++++++++++++++++++++
kernel/sched/fair.c | 51 ++++++-
kernel/sched/sched.h | 5 +
6 files changed, 441 insertions(+), 7 deletions(-)
create mode 100644 kernel/sched/energy_model.c
--
2.2.2
You have been invited to the following event.
Title: sched-dvfs design discussion
Link to Google HO is in the meeting details. If that doesn't work for
everyone then we can use some teleconf method.
The main purpose of the call is to discuss:
1) locking issues around get_cpu_usage
2) the polling nature of the current governor code and its implications
3) designing for the non-blocking DVFS case and for unification of task
placement and frequency selection decisions
When: Wed 2015-03-18 7:30am - 8:30am Pacific Time
Video call: https://plus.google.com/hangouts/_/linaro.org/sched-dvfs
<https://plus.google.com/hangouts/_/linaro.org/sched-dvfs?hceid=bWlrZS50dXJx…>
Calendar: Mike Turquette
Who:
* Mike Turquette - organizer
* Morten Rasmussen
* Amit Kucheria
* eas-dev(a)lists.linaro.org
* Vincent Guittot
* Juri Lelli
* Daniel Lezcano
* dietmar.eggemann(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=a2s1amRldW4zY28yMTdlY…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
eas-dev(a)lists.linaro.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.