From: rjw@sisk.pl (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3 0/5] coupled cpuidle state support
Date: Mon, 30 Apr 2012 23:25:09 +0200 [thread overview]
Message-ID: <201204302325.09505.rjw@sisk.pl> (raw)
In-Reply-To: <1335816551-27756-1-git-send-email-ccross@android.com>
Hi,
I have a comment, which isn't about the series itself, but something
thay may be worth thinking about.
On Monday, April 30, 2012, Colin Cross wrote:
> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> cpus cannot be independently powered down, either due to
> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> will corrupt the gic state unless the other cpu runs a work
> around). Each cpu has a power state that it can enter without
> coordinating with the other cpu (usually Wait For Interrupt, or
> WFI), and one or more "coupled" power states that affect blocks
> shared between the cpus (L2 cache, interrupt controller, and
> sometimes the whole SoC). Entering a coupled power state must
> be tightly controlled on both cpus.
That seems to be a special case of a more general situation where
a number of CPU cores belong into a single power domain, possibly along
some I/O devices.
We'll need to handle the general case at one point anyway, so I wonder if
the approach shown here may get us in the way?
> The easiest solution to implementing coupled cpu power states is
> to hotplug all but one cpu whenever possible, usually using a
> cpufreq governor that looks at cpu load to determine when to
> enable the secondary cpus. This causes problems, as hotplug is an
> expensive operation, so the number of hotplug transitions must be
> minimized, leading to very slow response to loads, often on the
> order of seconds.
This isn't a solution at all, rather a workaround and a poor one for that
matter.
> This patch series implements an alternative solution, where each
> cpu will wait in the WFI state until all cpus are ready to enter
> a coupled state, at which point the coupled state function will
> be called on all cpus at approximately the same time.
>
> Once all cpus are ready to enter idle, they are woken by an smp
> cross call.
Is it really necessary to wake up all of the CPUs in WFI before
going to deeper idle? We should be able to figure out when they
are going to be needed next time without waking them up and we should
know the latency to wake up from the deeper multi-CPU "C-state",
so it should be possible to decide whether or not to go to deeper
idle without the SMP cross call. Is there anything I'm missing here?
Rafael
next prev parent reply other threads:[~2012-04-30 21:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 20:09 [PATCHv3 0/5] coupled cpuidle state support Colin Cross
2012-04-30 20:09 ` [PATCHv3 1/5] cpuidle: refactor out cpuidle_enter_state Colin Cross
2012-05-03 20:50 ` Rafael J. Wysocki
2012-04-30 20:09 ` [PATCHv3 2/5] cpuidle: fix error handling in __cpuidle_register_device Colin Cross
2012-05-03 20:50 ` [linux-pm] " Rafael J. Wysocki
2012-04-30 20:09 ` [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus Colin Cross
2012-05-03 22:14 ` [linux-pm] " Rafael J. Wysocki
2012-05-03 23:09 ` Colin Cross
2012-05-04 11:51 ` Rafael J. Wysocki
2012-05-04 18:56 ` Colin Cross
2012-05-04 22:27 ` Rafael J. Wysocki
2012-04-30 20:09 ` [PATCHv3 4/5] cpuidle: coupled: add parallel barrier function Colin Cross
2012-04-30 20:09 ` [PATCHv3 5/5] cpuidle: coupled: add trace events Colin Cross
2012-05-03 21:00 ` Steven Rostedt
2012-05-03 21:13 ` Colin Cross
2012-04-30 21:18 ` [PATCHv3 0/5] coupled cpuidle state support Colin Cross
2012-04-30 21:25 ` Rafael J. Wysocki [this message]
2012-04-30 21:37 ` Colin Cross
2012-04-30 21:54 ` Rafael J. Wysocki
2012-04-30 22:01 ` Colin Cross
2012-05-03 20:00 ` Rafael J. Wysocki
2012-05-03 20:18 ` Colin Cross
2012-05-03 20:43 ` Rafael J. Wysocki
2012-05-04 10:04 ` Lorenzo Pieralisi
2012-05-01 10:43 ` Lorenzo Pieralisi
2012-05-02 0:11 ` Colin Cross
2012-05-02 7:22 ` Santosh Shilimkar
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=201204302325.09505.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-arm-kernel@lists.infradead.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).