Re: So, what's the status on the recent patches here?

Rafael J. Wysocki
2006-09-05T20:42:16Z

On Tuesday, 5 September 2006 18:03, Scott E. Preece wrote:
>
> | From: "Rafael J. Wysocki" <rjw@sisk.pl>
> |
> | On Monday, 4 September 2006 01:00, Scott E. Preece wrote:
> | > 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 think the decision to suspend is made
> | a) by the user,
> | b) by a policy manager in case when, for example, the battery is running
> | critical (ie. on emergency).
> | and the decision to change a frequency/voltage is usually based on some
> | efficiency factors.
> |
> | Also, the suspend "transitions" are never transparent to the user and the
> | changes of frequency/voltage usually are, at least as far as CPUs are
> | concerned.
> ---
>
> Your scope is too narrow. In our domain (mobile phones) the user has no
> control at all over power management and decisions to suspend are always
> transparent.
>
> In our own implementation, the user-space policy manager initiates
> frequency and voltage changes and enabled suspends, but doesn't actually
> initiate them. That is, the policy manager says "based on current user
> activity, it would be OK to suspend now", and a kernel component then
> looks for a good time to do it, based on the system being idle.

Okay, but it's not like that on a PC.

IMHO there are architectures on which suspend states are distinct and
therefore they should be treated as such in general.

> We have thought about merging the decisions into a single range of
> operating points, but the added plumbing to get idle information back to
> the policy manager seemed unappealing.
>
> We don't use cpufreq, so Pavel's arguments about not changing the kernel
> interface weren't a concern, for us. We're using a kernel interface that
> is all our own (and unappealingly ioctl-based).

Fine, as far as I'm concerned. ;-)

Greetings,
Rafael

--
You never change things by fighting the existing reality.
R. Buckminster Fuller