From: Morten Rasmussen <morten.rasmussen@arm.com>
To: peterz@infradead.org, mingo@kernel.org
Cc: rjw@rjwysocki.net, markgross@thegnar.org,
vincent.guittot@linaro.org, catalin.marinas@arm.com,
morten.rasmussen@arm.com, linux-pm@vger.kernel.org
Subject: [4/11] issue 4: Tracking idle states
Date: Fri, 20 Dec 2013 16:45:44 +0000 [thread overview]
Message-ID: <1387557951-21750-5-git-send-email-morten.rasmussen@arm.com> (raw)
In-Reply-To: <1387557951-21750-1-git-send-email-morten.rasmussen@arm.com>
Similar to the issue of knowing the potential capacity of a cpu, the CFS
scheduler also needs to know the idle state of idle cpus. Currently, an
idle cpu is found using cpumask_first() when an extra cpu is needed (for
nohz_idle_balance in find_new_ilb() in sched/fair.c). The energy
trade-off whether to wake another cpu or put tasks on already busy cpus
depend on this information.
The cost of waking up a cpu in terms of latency and energy depends on
the idle state the cpu is in. Deeper idle states typically affects more
than a single cpu. Waking up a single cpu from such state is more
expensive as it also affects the idle states of of its related cpus.
Energy costs are not currently represented in the cpuidle framework, but
latency is. Taking ARM TC2 as an example [1], which has two idle states:
Per-core clock-gating (WFI), and cluster power-down (power down all
related cpus and caches). The target residencies and exit latencies
specified in the driver give an idea about the cost involved in
entering/exiting these states.
Target Exit
residency latency
Clock-gating (WFI) 1 1
Cluster power-down 2000/2500 500/700 (big/LITTLE)
Picking the cheapest idle cpu would also have the effect that wake-ups
are likely to happen on the same cpu and leave the remaining cpus in
idle for longer.
Potential solution: Make the scheduler idle state aware by either moving
idle handling into the scheduler or let the idle framework (cpuidle)
maintain a cpumask of the cheapest cpus to wake up which is accessible
to the scheduler.
[1] drivers/cpuidle/cpuidle-big_little.c
next prev parent reply other threads:[~2013-12-20 16:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 16:45 [0/11] Energy-aware scheduling use-cases and scheduler issues Morten Rasmussen
2013-12-20 16:45 ` [1/11] issue 1: Missing power topology information in scheduler Morten Rasmussen
2013-12-22 15:19 ` mark gross
2013-12-30 14:00 ` Morten Rasmussen
2014-01-13 20:23 ` Rafael J. Wysocki
2014-01-14 16:21 ` Morten Rasmussen
2014-01-14 17:09 ` Peter Zijlstra
2013-12-20 16:45 ` [2/11] issue 2: Energy-awareness for heterogeneous systems Morten Rasmussen
2013-12-20 16:45 ` [3/11] issue 3: No understanding of potential cpu capacity Morten Rasmussen
2013-12-20 16:45 ` Morten Rasmussen [this message]
2013-12-20 16:45 ` [5/11] issue 5: Frequency and uarch invariant task load Morten Rasmussen
2013-12-20 16:45 ` [6/11] issue 6: Poor and non-deterministic performance on heterogeneous systems Morten Rasmussen
2013-12-20 16:45 ` [7/11] use-case 1: Webbrowsing on Android Morten Rasmussen
2013-12-20 16:45 ` [8/11] use-case 2: Audio playback " Morten Rasmussen
2014-01-07 12:15 ` Peter Zijlstra
2014-01-07 12:16 ` Peter Zijlstra
2014-01-07 16:02 ` Morten Rasmussen
2014-01-07 15:55 ` Morten Rasmussen
2013-12-20 16:45 ` [9/11] use-case 3: Video " Morten Rasmussen
2013-12-20 16:45 ` [10/11] use-case 4: Game " Morten Rasmussen
2013-12-20 16:45 ` [11/11] system 1: Saving energy using DVFS Morten Rasmussen
2013-12-22 16:28 ` [0/11] Energy-aware scheduling use-cases and scheduler issues mark gross
2013-12-30 12:10 ` Morten Rasmussen
2014-01-12 16:47 ` mark gross
2014-01-13 12:04 ` Catalin Marinas
-- strict thread matches above, loose matches on Subject: below --
2014-01-07 16:19 [0/11][REPOST] " Morten Rasmussen
2014-01-07 16:19 ` [4/11] issue 4: Tracking idle states Morten Rasmussen
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=1387557951-21750-5-git-send-email-morten.rasmussen@arm.com \
--to=morten.rasmussen@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-pm@vger.kernel.org \
--cc=markgross@thegnar.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rjw@rjwysocki.net \
--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).