On Sat, 5 Mar 2005, Pavel Machek wrote:
> Hi!
>
> > Now that 2.6.11 is out, we can start to address a number of important
> > issues for power management. This overview discusses some of them,
> > the things I have run across in my own work.
>
> Actually pm_message_t conversion is not be complete, yet, and it
> probably will not be complete before 2.6.13.
The issues in the previous email should be addressed before conversion can
be considered "complete".
> > In SMP systems, things would quickly get very confusing if
> > more the one processor was actively running during a sleep
> > transition. I don't know how this is handled currently, but
> > presumably it's not a major problem.
>
> We put all but one cpu in tight loop in smp_pause, so that it can't
> interfere. That's enough for STD, but not for STR.
What goes wrong during STR?
> > In STD, it's important that most processes do not run at all
> > once the memory image has been captured. In particular they
> > must not run while the image is being stored on the disk.
> > But sometimes a few processes have to be allowed to run (e.g.,
> > those needed for performing disk I/O). The scheduler must be
> > told that only processes marked PF_NOFREEZE can be allowed to
> > run.
>
> I'd say that refrigerator is the right way to do this for STD. If you
> have any other solution that does not impact fast paths in
> scheduler... that may be acceptable. Slowing down scheduler is not.
I don't know much about the scheduler. But if it can be made to ignore
processes that are in the refrigerator with no penalty, then it should be
able to ignore processes without PF_NOFREEZE also with no penalty.
> > An important difference between system sleep and selective suspend is
> > that with selective suspend, we generally expect the device to resume
> > on demand. This demand may take the form of a request to the driver
>
> Actually, we might want device to *not* resume on demand. ("My
> keyboard eats 5W and I only use mouse, anyway, suspend the keyboard!")
> That has very similar characteristics to system sleep... interrupts
> disabled, queues plugged, ...
True. The sysfs interface will need to support this kind of scenario
also.
Alan Stern
