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".
Umm, maybe, but we can't even switch pm_message_t to struct, yet,
because it would break the build.
> > > 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?
You'd have to boot secondary CPUs from real mode without touching
memory. Not easy.
> > 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.
Well, I don't want to know about scheduler. Take a look if you can
accomplish that. But having "if (in_suspend) { } " code in scheduler
is going to be ugly.
Ouch and it is not as easy as "ignore processes without
PF_NOFREEZE". You need them to sleep at defined place where they do
not hold any locks. What disadvantages do you see in refrigerator?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
