About TAU (and ICTC)

[Michel Lanners]

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 at cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: k_ppc_idled.c
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20010819/3eecfbc2/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ictc.diff
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20010819/3eecfbc2/attachment.asc>