sysctl support for ICTC

Hi all,

As an exercise ;-), I've added sysctl support for controlling and
displaying the contents of the G3 (and G4?) ICTC register.

What this register does: it slows down the rate at which instruction are
taken out of the L1 instruction cache for execution. Bit 31 (lowets bit)
enables the feature, the next 8 bits (23-31) define the number of clock
cycles to wait between instruction fetches.

Why it is useful: when combined with DPM (dynamic power management), the
effect of reducing the instrucion fetch rate is that DPM will more often
shut down the various execution units while being idle, thus reducing
power consumption and heat dissipation. This is good for battery life in
portable applications, since there's less power consumed in the
processor, and the fan can stay off (if combined with temperature
monitoring).

So, managing ICTC could be part of an intelligent apmd-style daemon
specifically for PPC.

If anyone wants to go ahead and implement that daemon, attached is the
ICTC part already ;-) It's a patch against kernel.org 2.2.17. It is
nothing intelligent, rather a copy of the existing l2cr support. It adds
an entry under the proc filesystem:

[mlan@piglet ~]$  cat /proc/sys/kernel/ictc
Instruction Cache Throttling Control:

0x0000000a:  disabled, delay: 5 clock cycles.

New values can be written thus:

[root@piglet /home/mlan]# echo 10 >/proc/sys/kernel/ictc


Have fun!

Michel

PS Also posted on sourceforge.

-------------------------------------------------------------------------
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. "

As an exercise ;-), I've added sysctl support for controlling and
displaying the contents of the G3 (and G4?) ICTC register.

Heh ! Nice ;) That's something I've wanted to do for years and never
ended up actually coding ;)

What this register does: it slows down the rate at which instruction are
taken out of the L1 instruction cache for execution. Bit 31 (lowets bit)
enables the feature, the next 8 bits (23-31) define the number of clock
cycles to wait between instruction fetches.

Why it is useful: when combined with DPM (dynamic power management), the
effect of reducing the instrucion fetch rate is that DPM will more often
shut down the various execution units while being idle, thus reducing
power consumption and heat dissipation. This is good for battery life in
portable applications, since there's less power consumed in the
processor, and the fan can stay off (if combined with temperature
monitoring).

So, managing ICTC could be part of an intelligent apmd-style daemon
specifically for PPC.

Well, I didn't think about that aspect of things with DPM.

The Darwin code has complete temperature control and uses the ICTC to
regulate it. That could be done from userland too on linux, by also
adding some support for the temp. registers.

If anyone wants to go ahead and implement that daemon, attached is the
ICTC part already ;-) It's a patch against kernel.org 2.2.17. It is
nothing intelligent, rather a copy of the existing l2cr support. It adds
an entry under the proc filesystem:

Well, put it on sourceforge, and if noone picks it up, I'll merge it one
of these days.

Ben.

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

Hi all,

Found something else re. power management...

On  12 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:

quoted

As an exercise ;-), I've added sysctl support for controlling and
displaying the contents of the G3 (and G4?) ICTC register.

Heh ! Nice ;) That's something I've wanted to do for years and never
ended up actually coding ;)

I know that feeling ;-))

quoted

So, managing ICTC could be part of an intelligent apmd-style daemon
specifically for PPC.

Well, I didn't think about that aspect of things with DPM.

The Darwin code has complete temperature control and uses the ICTC to
regulate it. That could be done from userland too on linux, by also
adding some support for the temp. registers.

Ah, temp registers. That's good, since IIRC there were a few atempts
long ago in this place to add temperature monitoring, but none ever
ended up with something useful. Finally, that 0 in the cpuinfo could be
replaced with something meaningful ;-)

Now, about conserving power on portable machines, there's another thing.
In the idle task, the processor (if supporting sleep) is put to either
NAP or DOZE mode (see arch/ppc/kernel/idle.c). NAP mode seems to save
more power, but there's no snooping. Don't know whether that would be a
problem... but I guess it could. Anyway, if somebody wants to
experiment, NAP can be enabled with
/proc/sys/kernel/powersave-nap.

Also, if the G4 supports power management, its PVR should be added to
power_save() in arch/ppc/kernel/idle.c, in preparation for G4 Powerbooks
;-)

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. "


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

Michel Lanners writes:

In the idle task, the processor (if supporting sleep) is put to either
NAP or DOZE mode (see arch/ppc/kernel/idle.c). NAP mode seems to save
more power, but there's no snooping. Don't know whether that would be a
problem... but I guess it could. Anyway, if somebody wants to
experiment, NAP can be enabled with
/proc/sys/kernel/powersave-nap.

When I tried on my 1999 G3 powerbook, it seemed to be that it used
more power in nap mode than in doze mode, so I leave it in doze mode.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

Michel Lanners wrote:

Ah, temp registers. That's good, since IIRC there were a few atempts
long ago in this place to add temperature monitoring, but none ever
ended up with something useful. Finally, that 0 in the cpuinfo could be
replaced with something meaningful ;-)

Motorola have recently revealed that you cannot enable both thermal and
decrementer interrupts simultaneously. In typical Motorola fashion, they
have published this hidden inside the manual for the 755, with a note
that it also applies to the 750.

I've posted patches for the temperature measurement a few times - all
you have to do is to use the correct bit numberings, rather than the
wrong ones that linger in the kernel headers like a bad cheese.

- Adrian Cox, AG Electronics

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