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 implementation of sleep transitions has gone reasonably smoothly,
> and people generally understand the problems and what still needs to
> be done. There's one thing I'd like to mention: the refrigerator.
> Ben H. has said that putting processes in the refrigerator at the
> start of a sleep transition is an unnecessary waste of time and I
> tend to agree, with a couple of provisos:
>
> 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.
> 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.
> Now it's time to consider how to implement additional power-saving
> measures -- in other words, selective suspends. Support currently is
> minimal and there are several important matters to settle.
>
> Typically selective suspend comes in two forms: drivers automatically
> reducing power usage by a device after a period of inactivity (let's
> call this "auto suspend"), and userspace-initiated changes carried out
> by writing to /sys/device/.../power/state ("user suspend"). They are
> rather different from system-wide sleep transitions, and each has its
> own set of problems.
...
> 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, ...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
