Hi!
> | Really, I think that the "states" which are entered only after tasks are
> | frozen should be considered as special and handled separately.
> ---
>
> My point is that if the only kernel interface is set-op(), then the code
> in the kernel that implements set-op() is the thing that's going to
> drive the details of suspending the system, just as it does today. The
> abstraction at the kernel interface is about as simple as it can be and
> all the policy issues are moved outside the kernel.
>
> My question is whether there are aspects of suspending, other than
> latency, that the policy manager would need to consider in deciding
> whether to suspend or not.
>
> Look at it this way. In one scheme the policy manager code is:
>
> new_OP = select_transition(current_OP, decision_factors);
> set_OP(new_OP);
No, it would be
new_OP = select_transition(current_OP, decision_factors);
if (new_OP == SUSPEND) {
setup wakeup events ...
}
set_OP(new_OP);
> in the other the policy manager code is:
>
> new_OP = select_transition(current_OP, decision_factors);
> if (new_OP == SUSPEND)
> suspend();
> else
> set_OP(new_OP);
...
> The one question that I see as interesting on that score is whether the
> policy decision to suspend is based on factors that are wholly different
> than the factors that drive frequency/voltage changes. If that were the
> case, then there would be no point to making the decisions in the same
> place. Honestly, I'm not sure of the answer to that...
I'm pretty sure decision to suspend is other factors. Remember most
machines are non-functional during suspend.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
