Re: [RFC] Power Management Policies

["Jordan Crouse" <jordan.crouse@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

Adam -

Excellent summary.

> On the other extreme, we could allow userspace to configure every
> timeout value, and other policy attributes. 

With regards to this specifically, in addition to the
other extremes you mentioned, we also have two different types of
systems. On one hand, we have open systems, with many different options,
and plenty of PCI and PCMCIA slots to keep adding new devices. while
on the other hand, we have closed systems such as cell phones and PDAs,
where the number of attached devices stays fairly constant.

>From a software point of view, the latter is usually controlled by a
operating environment (usually GUI based), that is developed by the
manufacturer and generally not hacked by the end user (most don't even
have terminals). And of course, Linux on an open system is usually
installed and hand tuned by the end user working closely with the
command line.  

So when it comes to a closed system, then I don't see any problem with
asking the userspace to configure everything about the policy, because
it gives the operating environment developer the most control over the
final device.  If someone down the line discovers that the wake
latency of a device is way too long, then I would much prefer that they
be able to tweak the settings via userspace, rather then have me patch a
new kernel just for them.

However, I can completely see where somebody responsible for an open
system would run in terror from this.  This would mean an immense amount
of work for the various distributions, as well as the inevitable
mailing list / technical support snafus that will occur when everybody
needs to figure out the various power management related quirks of their
various devices.

> I personally have some concerns over too much userspace interaction. 
> I think these decisions are too device specific, and if we don't take
> responsibility for them, then the layers above the kernel may not be
> able to properly handle it.

I generally favor the "user knows best" policy.  As developers, we will
make the best overall power management decisions for our drivers
(timeouts, system state transitions, etc, etc...), but should allow for
a facility for the user to override these if they so choose (possibly
through the policy manager).  We can even go so far as to make the
framework disabled by default in the kernel, so that one has to go in,
specifically choose it, and thereby take on the additional risk.  

Regards,
Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]