About TAU

Hi there,

Attached is a small patch that 'beautifies' the TAU options in the
kernel configuration (proper indent for TAU's suboptions). Ben, Paul,
could you push that part?

Also, Troy, would you mind adding a Config.help text for the TAU
options? I agree it's WIP and not all done yet; but at least we should
document that then ;-) It seems to me in PPC land we have the bad habit
of never providing Config.help texts... It's not done initially, and
when the feature stabilizes, it gets pushed to Linus without help texts
and stays that way forever. (hint, hint to all that haven't done the
help texts ;-)

Something else about an eventual TAU usage: Troy writes '...use cpu load
(from scheduler) and ICTC to extend battery life...'. That could
probably be done via something like i386's kapm_idled (kernel thread to
burn cycles efficiently, basically). Does that sound feasible?

Anybody know of any adverse effects of using ICTC to slow the CPU?
Bogompis and the kernel delay loop come to mind; don't know whether
those would need to be adjusted... which would be quite difficult, I
guess.

Ideas?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

Hi all,

I've thought a bit more about using ICTC...

On  19 Aug, this message from Michel Lanners echoed through cyberspace:

Something else about an eventual TAU usage: Troy writes '...use cpu load
(from scheduler) and ICTC to extend battery life...'. That could
probably be done via something like i386's kapm_idled (kernel thread to
burn cycles efficiently, basically). Does that sound feasible?

Attached is a first quick hack based on i386's kapm-idled. It creates a
thread that while running sets ICTC to some predefined value, thus
slowing down the CPU.

However, it seems to have the exact _opposite_ efect, in that it both
increases CPU temperature (from a displayed 4 C while idle to 12 C while
running this) and reduces battery life by about 30 min.

This is probably because the idle thread keeps the already-present
powersaving through the CPU's NAP and/or DOZE mode from kicking in.
On the other hand, the second patch adds an ICTC interface under
/proc/sys/kernel, based on the l2cr interface, so you can set arbitrary
ICTC values. You need to write ((slowdown_factor << 1) | enable);
slowdown_factor beeing between 0 and 255 processor cycles between
instruction fetches, and enable obviously being 1 to enable ICTC useage.

My preliminary test indicate that settig ICTC to 33 (0x21) has no
noticeable effect on an idle machine. While running an endless kernel
compile loop, however, it makes the CPU temperature drop from 19C to
15-17C, and increases battery life by about 20 min.

So, it would seem that ICTC has very limited use on an idle system,
whereas it could be useful under certain circumstances (low activity on
a battery-powered system; typically word processing on the morning
train). Obviously this makes setting ICTC automatically rather
difficult; it wold need to be set based on the machine load, and not on
the number of running processes as is done in my patch. Also, a separate
kernel thread seems counter-productive; it seems easier to just set and
clear ICTC in the idle loop (which does NAP/DOZE now), or even as a
userspace daemon, avoiding kernel code altogether.

It seems ICTC is best set according to user policy, so it would
definitely be a userspace thing.

Anybody know of any adverse effects of using ICTC to slow the CPU?
Bogompis and the kernel delay loop come to mind; don't know whether
those would need to be adjusted... which would be quite difficult, I
guess.

During my tests, I've not noticed any adverse effects apart from slowing
the machine down a bit.....

Please have a look at the patches, and test it for yourself ;-). All
temp/battery life data from my TiBook.

Cheers

Michel

PS To use the idle thread, drop k_ppc_idled.c into arch/ppc/kernel and
add k_ppc_idled.o in the Makefile over there.

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "

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/

At 2:51 PM -0500 8/19/2001, Timothy A. Seufert wrote:
[...]

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.

[...]

Hmm, I wonder how much thermal-resistive factors would affect this. Y'know,
generally when a circuit is warmer, it's resistance increases, and
subsequently it gets warmer, etc, so depending on how the curves weigh out
(if at all), there might be some hidden power savings in doing calculations
cooler and longer rather than warmer and shorter.

Maybe? I dunno.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Sun, 19 Aug 2001, Tony Mantler wrote:

Hmm, I wonder how much thermal-resistive factors would affect this. Y'know,
generally when a circuit is warmer, it's resistance increases, and
subsequently it gets warmer, etc, so depending on how the curves weigh out
(if at all), there might be some hidden power savings in doing calculations
cooler and longer rather than warmer and shorter.

Heat is proportional to power dissipation:

    P = UI

while

    I = U/R

So if R increases, I decreases. But then P decreases too and the IC gets
cooler, hence less resistance. Hmm...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

At 3:43 PM -0500 8/19/2001, Geert Uytterhoeven wrote:

On Sun, 19 Aug 2001, Tony Mantler wrote:

quoted

Hmm, I wonder how much thermal-resistive factors would affect this. Y'know,
generally when a circuit is warmer, it's resistance increases, and
subsequently it gets warmer, etc, so depending on how the curves weigh out
(if at all), there might be some hidden power savings in doing calculations
cooler and longer rather than warmer and shorter.

Heat is proportional to power dissipation:

   P = UI

while

   I = U/R

So if R increases, I decreases. But then P decreases too and the IC gets
cooler, hence less resistance. Hmm...

That works for a lightbulb, but remember that what we're really trying to
do inside an IC is to charge a capacitive circuit: the transistor gate.

So if we think of the transistor gate as just a capacitor for a moment,
ignoring the source and drain, we'll need to dump in a certain amount of
energy before it goes from an effective-conductive state to an
effective-nonconductive state (ramping through a psuedo-resistive state
between the two). More input resistance means that the circuit stays in the
psuedo-resistive state longer, meanwhile sending the balance of the energy
out as heat through the input resistance.

Effectively what that translates into is automatically draining more power
to switch the transistor. Of course, more power undeniably means more heat.

Remember that even for the simplest circuit, the voltage:resistance->heat
curve is definatley not linear. (often even having multiple steady states
per voltage:resistance)


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

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.

Unfortunately, the TAU is too badly calibrated to be useful. There
_might_ be some other temp sensors in recent Apple machines, on the
I2C bus, I'll do some "probing" one of these days.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michel Lanners writes:

My preliminary test indicate that settig ICTC to 33 (0x21) has no
noticeable effect on an idle machine. While running an endless kernel
compile loop, however, it makes the CPU temperature drop from 19C to
15-17C, and increases battery life by about 20 min.

How long did each kernel compile take, with ICTC=0 and ICTC=0x21, and
what was the average current consumption in each case?

I would expect that the total battery charge used could well be higher
with ICTC=0x21 than with ICTC=0, particularly if you had the LCD
backlight on during the compile. :)

Regards,
Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/