From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: RFC: Dynamic hwcaps
Date: Sun, 5 Dec 2010 15:12:42 +0100 [thread overview]
Message-ID: <20101205151242.298922ad@surf> (raw)
In-Reply-To: <AANLkTikWgWWubP9VozvUtA92N-BWyUFRp7ykCho8itMA@mail.gmail.com>
Hi,
On Fri, 3 Dec 2010 16:28:27 +0000
Dave Martin <dave.martin@linaro.org> wrote:
> This allows for more active power management of such functional
> blocks: if the CPU is not fully loaded, you can turn them off -- the
> kernel can spot when there is significant idle time and do this. If
> the CPU becomes fully loaded, applications which have soft-realtime
> constraints can notice this and switch to their accelerated code
> (which will cause the kernel to switch the functional unit(s) on).
> Or, the kernel can react to increasing CPU load by speculatively turn
> it on instead. This is analogous to the behaviour of other power
> governors in the system. Non-aware applications will still work
> seamlessly -- these may simply run accelerated code if the hardware
> supports it, causing the kernel to turn the affected functional
> block(s) on.
>From a power management perspective, is it really useful to load the
CPU instead of using specialized units which usually provide more
computing power per watt consumed ?
When the CPU is idle, it can enter sleep states to save power and let a
more specialized unit do the optimized work. For example, when doing
video decoding, probably specialized DSPs to a much better job from a
power management perspective than the CPU would do, so it's better to
keep the CPU idle and let the DSP do its video decoding job. No?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2010-12-05 14:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-03 16:28 RFC: Dynamic hwcaps Dave Martin
2010-12-03 16:43 ` Jesse Barker
2010-12-03 16:51 ` Russell King - ARM Linux
2010-12-03 17:35 ` Dave Martin
2010-12-05 15:14 ` Mark Mitchell
2010-12-06 11:07 ` Dave Martin
2010-12-07 1:02 ` Mark Mitchell
2010-12-07 10:45 ` Dave Martin
2010-12-07 11:04 ` Russell King - ARM Linux
2010-12-07 15:06 ` Dave Martin
2010-12-07 15:21 ` Russell King - ARM Linux
2010-12-07 15:36 ` Dave Martin
2010-12-05 14:12 ` Thomas Petazzoni [this message]
2010-12-06 10:56 ` Dave Martin
2010-12-08 11:01 ` Jamie Lokier
2010-12-08 11:07 ` Dave Martin
2010-12-07 21:15 ` Ben Dooks
2010-12-08 10:30 ` Dave Martin
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=20101205151242.298922ad@surf \
--to=thomas.petazzoni@free-electrons.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.