From: "Timothy A. Seufert" <tas@mindspring.com>
To: mlan@cpu.lu, hozer@drgw.net
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: About TAU (and ICTC)
Date: Sun, 19 Aug 2001 12:51:31 -0700 [thread overview]
Message-ID: <p05100301b7a5c073cc62@[10.0.0.42]> (raw)
In-Reply-To: <200108191559.RAA01163@piglet.grunz.lu>
Michel,
I'd have to agree. ICTC policy should really be userspace, as should
all policy.
The exception would be when it's desired to use the feature for its
original intended purpose, reduction of die temperature when that
temperature reaches a critical threshold. That would also mean using
the TAU the way it was intended: you set the upper and lower TAU
thresholds as desired, and the TAU ISR turns ICTC on when the high
threshold is passed and off when it moves past the lower.
Even in that scenario, userspace should enable/disable thermal
throttling and its thresholds, probably via /proc entries.
I'm actually not sure it makes sense to use ICTC as a powersave
feature. The way it works is simply by making use of the dynamic
powersave feature built into the CPU -- functional units that aren't
being used aren't clocked. Decrease the frequency of use and you
decrease the rate of power consumption.
But if you think about it, it probably doesn't reduce the total power
needed to do a given task. It just spreads the power use over a
longer period of time. So you'll use roughly the same amount of
energy to do one kernel compile no matter what the ICTC setting is;
it'll just get done slower with ICTC on.
In fact, because programs will generally take longer to run with ICTC
on, I suspect that ICTC is *less* power efficient than going all-out.
Only part of the CPU's power use is dynamic (and therefore subject to
regulation via ICTC). There's dielectric leakage current, which is
constant no matter what you do, and, more importantly, plenty of
clocked circuits which are not shut down by the dynamic power save
circuitry. From this one can conclude that power use per unit of
computation done is likely higher when using ICTC.
Could you test this? I.e. run a continuous kernel compile and record
not only how long the battery lasts but how many compiles got done
before the end.
(It's probably for this reason that Apple uses variable clock speed
rather than ICTC to save power on their recent portables. For
example the new model iBook normally runs at 500 MHz, but can switch
down to 400 MHz while on battery power.)
--
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-08-19 19:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-19 10:03 About TAU Michel Lanners
2001-08-19 15:59 ` About TAU (and ICTC) Michel Lanners
2001-08-19 19:51 ` Timothy A. Seufert [this message]
2001-08-19 20:08 ` Tony Mantler
2001-08-19 20:43 ` Geert Uytterhoeven
2001-08-19 21:23 ` Tony Mantler
2001-08-19 22:02 ` Benjamin Herrenschmidt
2001-08-19 23:57 ` Paul Mackerras
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='p05100301b7a5c073cc62@[10.0.0.42]' \
--to=tas@mindspring.com \
--cc=hozer@drgw.net \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mlan@cpu.lu \
/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).