cpufreq.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mason <mpeg.blue@free.fr>
To: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	cpufreq <cpufreq@vger.kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Pavel Machek <pavel@ucw.cz>,
	Mike Turquette <mturquette@linaro.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: cpuidle vs suspend vs something else
Date: Thu, 05 Feb 2015 19:13:07 -0800	[thread overview]
Message-ID: <54D43143.2010403@free.fr> (raw)

Hello everyone,

I've been reading about related sub-systems (cpuidle and suspend)
and I'm not sure I understand how they relate / interact.

If I understand correctly (please do point out any misconceptions)
on ARM Cortex A9, the first level of power saving is WFI, which is
typically called from the idle loop.

This places the core in low-power mode ("Standby mode" in ARM docs).
"RAM arrays" (don't know what they are), "processor logic", and
"data engine" (not sure what any of these exactly refers to, guess
I have more reading to do) are still powered-up, but most of the
clocks are disabled.

In ARM's exact words, "WFI and WFE Standby modes disable most of the
clocks in a processor, while keeping its logic powered up. This reduces
the power drawn to the static leakage current, leaving a tiny clock
power overhead requirement to enable the device to wake up."

Some CPUs like Intel's have several levels of sleep (deeper levels
mean less power, but have a higher wake-up latency). AFAIU, cpuidle
is used to describe and manage these levels?

Isn't suspend somewhat like the deepest level of sleep?
(Or is it different in that things like RAM state are only a concern
for suspend, not cpuidle?)

Are both subsystems still actively used?

I saw plans to merge cpufreq into cpuidle / scheduler decisions.

LCA14: LCA14-306: CPUidle & CPUfreq integration with scheduler
http://www.slideshare.net/linaroorg/lca14-306-cpuidlecpufreqintegrationwithscheduler

This presentation doesn't mention suspend, I think.

ARM has a mode called "Dormant Mode". Is suspend typically
used to put the SoC in that mode?

I think I need to read this document carefully:
Power Management In The Linux Kernel -- Current Status And Future
http://events.linuxfoundation.org/sites/events/files/slides/kernel_PM_plain.pdf

There's also an older document that may prove insightful:
CPUIdle versus Suspend
http://www.linuxplumbersconf.org/2010/ocw/proposals/789

But things move so fast in kernel-land, that I don't know how relevant
a 4 year-old document can be.

Regards.


             reply	other threads:[~2015-02-06  3:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-06  3:13 Mason [this message]
2015-02-06  8:37 ` cpuidle vs suspend vs something else Krzysztof Kozlowski
2015-02-06 18:49 ` Mike Turquette
2015-02-06 21:21 ` Pavel Machek

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=54D43143.2010403@free.fr \
    --to=mpeg.blue@free.fr \
    --cc=cpufreq@vger.kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mturquette@linaro.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).