[linux-pm] So, what's the status on the recent patches here?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, 5 September 2006 18:03, Scott E. Preece wrote:
> 
> | From: "Rafael J. Wysocki" <rjw at 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


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux