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