From: Michael Schmitz <hidden> Date: 2000-11-23 08:47:13
quoted
Linux-PPC (basically the Apple computers, any other Linux/PPC-subset
using it ?) uses the PMU, and pmud for power management. I don't think
that anybody wants to write an APM support for Power Macs (not me
anyway).
Not APM support exactly... simply support for the same interface. Just like
powermacs have totally different sound systems and still use /dev/dsp.
/proc/apm and /dev/apm_bios are so simple that it should be easy to convince
any power management system to provide those API's.
The info logged to /proc/apm is currently logged to /etc/power/apm. I have
no idea what /dev/apm does aside from providing that log info, and I have
no clue what /dev/apm_bios does, either. There should be no major problems
duplicating the pmu logging code in the kernel, and interfacing that with
some apm glue code, assuming the apm interface is reasonably architecture
independent. I just don't see a good reason to change from pmud to apmd,
if that's what you're suggesting.
CC: to linuxppc-dev where this discussion really should be.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-11-24 13:40:41
quoted
Not APM support exactly... simply support for the same interface.
Just like
quoted
powermacs have totally different sound systems and still use /dev/dsp.
/proc/apm and /dev/apm_bios are so simple that it should be easy to
convince
quoted
any power management system to provide those API's.
The info logged to /proc/apm is currently logged to /etc/power/apm. I have
no idea what /dev/apm does aside from providing that log info, and I have
no clue what /dev/apm_bios does, either. There should be no major problems
duplicating the pmu logging code in the kernel, and interfacing that with
some apm glue code, assuming the apm interface is reasonably architecture
independent. I just don't see a good reason to change from pmud to apmd,
if that's what you're suggesting.
At least one reason: the current pmud does continuous polling of the PMU
via /dev/pmu. On newer (core99) machines, the PMU itself will send
messages to the CPU when any environement info change (battery status,
lid closed, ...). We currently don't use this feature and so end up
communicating with the PMU more than we would really need.
We can "fix" that by either having the PMU driver on core99 continuously
send those infos via /dev/pmu without explicit request. It may also be
interesting to replace this by a kernel thread. That would allow more
flexibility in communicating with userland (things like signaling
processes that asked for it to be notified of a sleep request, etc...).
One other issue we have with sleep is that we need to prevent the kernel
to do a bunch of thigns while going to sleep. scheduling from within the
sleep ioctl is dangerous, but will happen occasionally, especially when
sleeping & waking up the IDE layer.
I beleive it should be possible to hack the scheduler so that only our
sleep thread gets scheduled at all (disabling scheduling on the main CPU
and freezing other CPUs in sleep loops) during the sleep & wakeup process.
Any better ideas ?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-11-24 14:29:07
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
We can "fix" that by either having the PMU driver on core99 continuously
send those infos via /dev/pmu without explicit request. It may also be
interesting to replace this by a kernel thread. That would allow more
flexibility in communicating with userland (things like signaling
processes that asked for it to be notified of a sleep request, etc...).
Could the recently added keventd thread be used for this? I don't like the
idea of adding kernel threads just for one thing. One kernel thread for
all relatively slow operations which may need a process context is
reasonable however.
One other issue we have with sleep is that we need to prevent the kernel
to do a bunch of thigns while going to sleep. scheduling from within the
sleep ioctl is dangerous, but will happen occasionally, especially when
sleeping & waking up the IDE layer.
I beleive it should be possible to hack the scheduler so that only our
sleep thread gets scheduled at all (disabling scheduling on the main CPU
and freezing other CPUs in sleep loops) during the sleep & wakeup process.
Any better ideas ?
No, I thought the deep sleep modes were only for laptops which are not SMP
unless I missed some recent Apple announcement ;-). Do SMP G4 truly
require complex power management ?
BTW: I dislike any idea of playing with the scheduler.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-11-24 15:33:20
Could the recently added keventd thread be used for this? I don't like the
idea of adding kernel threads just for one thing. One kernel thread for
all relatively slow operations which may need a process context is
reasonable however.
I'll investigate.
No, I thought the deep sleep modes were only for laptops which are not SMP
unless I missed some recent Apple announcement ;-). Do SMP G4 truly
require complex power management ?
Yup. Almost all Apple recent machines can do power management in various
ways. Some can deep sleep (not only portables), all can switch off power
to some PCI devices & ASICs, some support turning off the CPU...
BTW: I dislike any idea of playing with the scheduler.
Me too. The problem is that the IDE layer will always schedule if you do
something more complex that setting a few registers. scheduling in the
middle of putting things to sleep is bad, except is drivers that have
already been put to sleep can cope with it by just blocking userland IOs
or returning errors.
For other CPUs, I beleive we can go with a cross-CPU function call, the
called function putting the other CPU in a spin-loop. My problem with
that is that it happens all at interrupt time, which may not be the best
place to put the CPU to sleep. Maybe I can manage to schedule a bottom
half or soemthing like that.
Apple's code is smarter in that sense that they can apparently easily
turn CPUs on/off (putting them in sleep loops when they are off), causing
all processes to migrate to the still running CPU. However, AFAIK, their
current Darwin kernel cannot sleep on SMP machines properly neither yet.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-11-24 16:26:27
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
Yup. Almost all Apple recent machines can do power management in various
ways. Some can deep sleep (not only portables), all can switch off power
to some PCI devices & ASICs, some support turning off the CPU...
Ok, I don't see very much the point of saving fractions of watt on a
desktop but...
quoted
BTW: I dislike any idea of playing with the scheduler.
Me too. The problem is that the IDE layer will always schedule if you do
something more complex that setting a few registers. scheduling in the
middle of putting things to sleep is bad, except is drivers that have
already been put to sleep can cope with it by just blocking userland IOs
or returning errors.
Returning errors to user mode looks like a bad idea, it should be
absolutely transparent to applications.
For other CPUs, I beleive we can go with a cross-CPU function call, the
called function putting the other CPU in a spin-loop. My problem with
that is that it happens all at interrupt time, which may not be the best
place to put the CPU to sleep. Maybe I can manage to schedule a bottom
half or soemthing like that.
I'm lost. Can't power management be done by the idle task ? There is one
per CPU but it can't handle signala AFAIR. After all power management
seems better handled by a task which never does I/O and whose only purpose
is to sleep...
Apple's code is smarter in that sense that they can apparently easily
turn CPUs on/off (putting them in sleep loops when they are off), causing
all processes to migrate to the still running CPU. However, AFAIK, their
current Darwin kernel cannot sleep on SMP machines properly neither yet.
What do you call a sleep loop ?
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-11-24 17:31:05
Ok, I don't see very much the point of saving fractions of watt on a
desktop but...
It can be more than fraction of watts when you put it all together, especially
in deep sleep. And multiply that by the number of machines out there...
Also, the Cube is sensitive to heat problems, having some power
management (and CPU temp control, but that's another issue) helps.
Returning errors to user mode looks like a bad idea, it should be
absolutely transparent to applications.
Well, that depends. I prefer blocking them, definitely, but that may not
always be possible.
Some things can just not be handled this way. We cannot, for example,
afford to schedule (or even printk) after the video driver have put the
chip to sleep. That's why we have these ordering rules x86 lacks, so that
we can sleep this driver very late in the sleep process, and wake it up
first. In the case of SMP boxes, we would have needed to put the other
CPUs to sleep before that point.
I'm lost. Can't power management be done by the idle task ? There is one
per CPU but it can't handle signala AFAIR. After all power management
seems better handled by a task which never does I/O and whose only purpose
is to sleep...
That could be done this way too. Are there any guarantees that the idle
task will run at all, however, if a process is using all the available
CPU time ? If we need all processors to stop scheduling userland code and
wait in a sleep loop (not doze nor nap in this case), we need to have a
way to let the idle task know that we need it to enter this special sleep
stage ASAP. It will have to flush all caches properly and go to sleep. On
some boxes, the CPU(s) will be shut down and revived via ROM hooks.
What do you call a sleep loop ?
An infinite loop where the CPU goes to sleep mode. It exists via an
external reset or CPU shut down.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
quoted
Ok, I don't see very much the point of saving fractions of watt on a
desktop but...
It can be more than fraction of watts when you put it all together, especially
in deep sleep. And multiply that by the number of machines out there...
Also, the Cube is sensitive to heat problems, having some power
management (and CPU temp control, but that's another issue) helps.
That's what I call `solving hardware problems by software'. Gives some bonus
points in the old Hackers' Test :-)
quoted
I'm lost. Can't power management be done by the idle task ? There is one
per CPU but it can't handle signala AFAIR. After all power management
seems better handled by a task which never does I/O and whose only purpose
is to sleep...
That could be done this way too. Are there any guarantees that the idle
task will run at all, however, if a process is using all the available
CPU time ? If we need all processors to stop scheduling userland code and
wait in a sleep loop (not doze nor nap in this case), we need to have a
way to let the idle task know that we need it to enter this special sleep
stage ASAP. It will have to flush all caches properly and go to sleep. On
some boxes, the CPU(s) will be shut down and revived via ROM hooks.
quoted
What do you call a sleep loop ?
An infinite loop where the CPU goes to sleep mode. It exists via an
external reset or CPU shut down.
What about putting all CPUs except one to sleep at night?
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/
From: Gabriel Paubert <hidden> Date: 2000-11-24 19:27:32
On Fri, 24 Nov 2000, Benjamin Herrenschmidt wrote:
quoted
Ok, I don't see very much the point of saving fractions of watt on a
desktop but...
It can be more than fraction of watts when you put it all together, especially
in deep sleep. And multiply that by the number of machines out there...
Don't worry. Intel and M$ contribute much more to global warming :-)
Also, the Cube is sensitive to heat problems, having some power
management (and CPU temp control, but that's another issue) helps.
Ok, style over substance. Remind me to never buy a cube...
quoted
Returning errors to user mode looks like a bad idea, it should be
absolutely transparent to applications.
Well, that depends. I prefer blocking them, definitely, but that may not
always be possible.
Some things can just not be handled this way. We cannot, for example,
afford to schedule (or even printk) after the video driver have put the
chip to sleep. That's why we have these ordering rules x86 lacks, so that
we can sleep this driver very late in the sleep process, and wake it up
first. In the case of SMP boxes, we would have needed to put the other
CPUs to sleep before that point.
quoted
I'm lost. Can't power management be done by the idle task ? There is one
per CPU but it can't handle signala AFAIR. After all power management
seems better handled by a task which never does I/O and whose only purpose
is to sleep...
That could be done this way too. Are there any guarantees that the idle
task will run at all, however, if a process is using all the available
CPU time ? If we need all processors to stop scheduling userland code and
wait in a sleep loop (not doze nor nap in this case), we need to have a
way to let the idle task know that we need it to enter this special sleep
stage ASAP. It will have to flush all caches properly and go to sleep. On
some boxes, the CPU(s) will be shut down and revived via ROM hooks.
I believe the idle task blocks all signals, but once in the idle task you
can check for pending signals (signal_pending(current)) which would be a
way to communicate with it. It might be necessary to raise the priority of
the idle task when you send it a signal (and set need_resched to schedule
asap). The idle task would lower its own priority later when exiting from
sleep. This might be a way to provide a known clean context for power
management (and there is one idle task per processor as I said earlier).
The scheduler should not need any change. Of course raising the priority
of the idle task may seem strange, but when you risk overheating, it's
urgent to become idle...
BTW: I don't want to ever enter sleep state on my machines, a stopped
timebase would be a catastrophe when you need accurate timestamps. Nap and
doze are still ok, currently only the first level is entered. I'm not even
sure it's worth going to the second level on machines which have a
continuous stream of interrupts at >100Hz, flushing and reloading the
cache at this rate is probably not a power saving measure when the active
part of the memory fits in the L2 cache.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/