From: Colin Cross <ccross@android.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-pm@lists.linux-foundation.org,
Len Brown <len.brown@intel.com>, Kevin Hilman <khilman@ti.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Amit Kucheria <amit.kucheria@linaro.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Trinabh Gupta <g.trinabh@gmail.com>,
Deepthi Dharwar <deepthi@linux.vnet.ibm.com>,
linux-omap@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH 0/3] coupled cpuidle state support
Date: Fri, 20 Jan 2012 12:40:03 -0800 [thread overview]
Message-ID: <CAMbhsRTbVqV6p0py9NGZrpFPf2yvp-B0dr+o-m7qbdja_-Lfzw@mail.gmail.com> (raw)
In-Reply-To: <4F1929E9.7070707@linaro.org>
On Fri, Jan 20, 2012 at 12:46 AM, Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
> Hi Colin,
>
> this patchset could be interesting to resolve in a generic way the cpu
> dependencies.
> What is the status of this patchset ?
I can't do much with it right now, because I don't have any devices
that can do SMP idle with a v3.2 kernel. I've started working on an
updated version that avoids the spinlock, but it might be a while
before I can test and post it. I'm mostly looking for feedback on the
approach taken in this patch, and whether it will be useful for other
SoCs besides Tegra and OMAP4.
> Did you have the opportunity to measure the power consumption with and
> without this patchset ?
Power consumption will be very dependent on the specific SoC in
question. The most important factors are the power savings of the
independent cpuidle state (normally WFI) vs. the hotplug state
(normally 1 cpu in OFF), and the workload being tested.
On a very idle system, these patches result in the same total power as
hotplugging one cpu and letting the other idle normally. On a 25%
busy system, you might see a slight increase in power, as the best
independent cpuidle state might be WFI, vs 1 cpu in OFF mode in
hotplug. On OMAP4, that difference is small, on the order of 10 mW.
Once you hit the threshold where a hotplug governor would have
hotplugged in the second cpu (lets say 40%), the savings from these
patches are enormous, as you can hit the lowest power state up to 60%
of the time, where the hotplug solution would never be going below WFI
on both cpus. On OMAP4, that can be well over 100 mW.
next prev parent reply other threads:[~2012-01-20 20:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-21 0:09 [PATCH 0/3] coupled cpuidle state support Colin Cross
2011-12-21 0:09 ` [PATCH 1/3] cpuidle: refactor out cpuidle_enter_state Colin Cross
2012-01-04 14:08 ` [linux-pm] " Jean Pihet
2011-12-21 0:09 ` [PATCH 2/3] cpuidle: fix error handling in __cpuidle_register_device Colin Cross
2011-12-21 0:09 ` [PATCH 3/3] cpuidle: add support for states that affect multiple cpus Colin Cross
2011-12-21 9:02 ` [PATCH 0/3] coupled cpuidle state support Arjan van de Ven
2011-12-21 9:40 ` Colin Cross
2011-12-21 9:44 ` Arjan van de Ven
2011-12-21 9:55 ` Colin Cross
2011-12-21 12:12 ` Arjan van de Ven
2011-12-21 19:05 ` Colin Cross
2011-12-21 19:36 ` Arjan van de Ven
2011-12-21 19:42 ` [linux-pm] " Colin Cross
2011-12-22 8:35 ` Shilimkar, Santosh
2011-12-22 8:53 ` Arjan van de Ven
2011-12-22 9:30 ` Shilimkar, Santosh
2011-12-22 21:20 ` Colin Cross
2012-03-14 0:39 ` Colin Cross
2012-01-04 0:41 ` Kevin Hilman
2012-01-04 17:27 ` Shilimkar, Santosh
2012-01-20 8:46 ` Daniel Lezcano
2012-01-20 20:40 ` Colin Cross [this message]
2012-01-25 14:04 ` Daniel Lezcano
2012-01-31 14:13 ` Daniel Lezcano
2012-01-27 8:54 ` [linux-pm] " Vincent Guittot
2012-01-27 17:32 ` Colin Cross
2012-02-01 12:13 ` Vincent Guittot
2012-02-01 14:59 ` Lorenzo Pieralisi
2012-02-01 17:30 ` Colin Cross
2012-02-01 18:07 ` Lorenzo Pieralisi
2012-02-03 1:19 ` Colin Cross
[not found] ` <8762e8kqi6.fsf@ti.com>
2012-03-14 0:28 ` Colin Cross
2012-03-14 0:47 ` Colin Cross
2012-03-14 14:23 ` [linux-pm] " Kevin Hilman
2012-03-14 2:04 ` Arjan van de Ven
2012-03-14 2:21 ` Colin Cross
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=CAMbhsRTbVqV6p0py9NGZrpFPf2yvp-B0dr+o-m7qbdja_-Lfzw@mail.gmail.com \
--to=ccross@android.com \
--cc=amit.kucheria@linaro.org \
--cc=arjan@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=deepthi@linux.vnet.ibm.com \
--cc=g.trinabh@gmail.com \
--cc=khilman@ti.com \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-tegra@vger.kernel.org \
--cc=santosh.shilimkar@ti.com \
/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).