[RFC] Power Management Policies

[RFC] Power Management Policies

[Adam Belay]

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


Hi All,

I was wondering if you had any thoughts on how power management policies
should be configured by userspace.  It seems like the central question
here is how much of the decision should occur in kernel-space.

For example, on one extreme we could have each policy manager define a
list of policies and allow the user to select one.  So, in my model, the
user might tell a "power device" to use the policy "max performance" or
"emergency power-save".  One could argue that these decisions are too
complex and device specific for userspace to be reliable.  It would give
the driver author, who likely has extensive knowledge of the pm
capabilities of the device, a chance to include power management
policies with the driver.

On the other extreme, we could allow userspace to configure every
timeout value, and other policy attributes.  The user would be in
complete control, but may not be aware of how long the transitions will
take, how much power will be consumed by the transition, or what the
manufacturer intended.  If the user wanted a disk drive to turn off
after 1 ms of inactivity, there would be nothing stopping that.  Of
course, one could argue that the kernel shouldn't be making policy
decisions, and we should throw these toward the layer above us.

One other option is to allow userspace to actually tell the devices
which state to switch to.  I'd argue against this, because I think that
userspace cannot disable a device that it needs to function.

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.  Also I think that some decisions may need
to be made very quickly.  In the end, we will probably make a compromise
between these extremes.  I would appreciate any opinions or suggestions.

Thanks,
Adam



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

Re: [RFC] Power Management Policies

[Jordan Crouse]

[-- 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 --]

Re: [RFC] Power Management Policies

[Pavel Machek]

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

Hi!

> > 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.

Notebooks and PDAs are not that different. Both are mostly closed with pcmcia/cf/sd slot...

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         


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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Friday 22 April 2005 1:05 pm, Pavel Machek wrote:
> Hi!
> 
> > > 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.
> 
> Notebooks and PDAs are not that different. Both are mostly closed with pcmcia/cf/sd slot...

And, whoops, USB ... which lets systems expand easily.  If the device
supports a hub, then you (or, more accurately, crazy people!) could
add over a hundred devices.  That's pretty "open".

AFAICT the hardware folk are more than ready to start providing hand-held
devices (PDA-ish, vs luggable laptops) with USB host capabilities.  But
WinCE isn't ready for that yet though... ergo products don't do it yet.
Linux has less trouble, since market positioning doesn't interfere.  :)

- Dave

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

Re: [RFC] Power Management Policies

[Pavel Machek]

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

Hi!

> > > > 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.
> > 
> > Notebooks and PDAs are not that different. Both are mostly closed with pcmcia/cf/sd slot...
> 
> And, whoops, USB ... which lets systems expand easily.  If the device
> supports a hub, then you (or, more accurately, crazy people!) could
> add over a hundred devices.  That's pretty "open".
> 
> AFAICT the hardware folk are more than ready to start providing hand-held
> devices (PDA-ish, vs luggable laptops) with USB host capabilities.  But
> WinCE isn't ready for that yet though... ergo products don't do it yet.
> Linux has less trouble, since market positioning doesn't interfere.  :)

USB zauruses could do that for >2 years now, and even recent windows
CE devices frequently list USB host capabilities... (Or USB on-the-go
which is similar, AFAICT).
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Wednesday 27 April 2005 7:48 am, Pavel Machek wrote:
> > 
> > AFAICT the hardware folk are more than ready to start providing hand-held
> > devices (PDA-ish, vs luggable laptops) with USB host capabilities.  But
> > WinCE isn't ready for that yet though... ergo products don't do it yet.
> > Linux has less trouble, since market positioning doesn't interfere.  :)
> 
> USB zauruses could do that for >2 years now,

Which ones?  The ones I know about have a peripheral controller,
not a host controller.   There's a recent iPaq that uses OHCI
on a pxa27x to contact an on-board bluetooth adapter.  But AFAIK,
PDAs with an USB host _connector_ is pretty rare.  (There's a
CF/IO card adapter I've seen, but that's not quite the same.)


> and even recent windows 
> CE devices frequently list USB host capabilities... (Or USB on-the-go
> which is similar, AFAICT).

Well, you may be watching those WinCE devices more closely than
me, but all I've noticed in that respect is spec-ware support
for host side capabilities... with even that being scarce.
I'd be glad to see that improving though!

For USB OTG devices, a Mini-AB connector can act as either host
or peripheral; and can switch roles later.  Hub support is
optional, so it's not necessarily as flexible as one might like.
But yes, once that starts to catch on, it should be interesting.

- Dave

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

Re: [RFC] Power Management Policies

[Pavel Machek]

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

Hi!

> > > AFAICT the hardware folk are more than ready to start providing hand-held
> > > devices (PDA-ish, vs luggable laptops) with USB host capabilities.  But
> > > WinCE isn't ready for that yet though... ergo products don't do it yet.
> > > Linux has less trouble, since market positioning doesn't interfere.  :)
> > 
> > USB zauruses could do that for >2 years now,
> 
> Which ones?  The ones I know about have a peripheral controller,
> not a host controller.   There's a recent iPaq that uses OHCI
> on a pxa27x to contact an on-board bluetooth adapter.  But AFAIK,
> PDAs with an USB host _connector_ is pretty rare.  (There's a
> CF/IO card adapter I've seen, but that's not quite the same.)

sl-5500 has peripheral controller, but sl-5600 and newer should have a
host controller. [Unfortunately mine is 5500.]

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Thursday 28 April 2005 1:23 am, Pavel Machek wrote:
> Hi!
> 
> > > > AFAICT the hardware folk are more than ready to start providing hand-held
> > > > devices (PDA-ish, vs luggable laptops) with USB host capabilities.  But
> > > > WinCE isn't ready for that yet though... ergo products don't do it yet.
> > > > Linux has less trouble, since market positioning doesn't interfere.  :)
> > > 
> > > USB zauruses could do that for >2 years now,
> > 
> > Which ones?  The ones I know about have a peripheral controller,
> > not a host controller.   There's a recent iPaq that uses OHCI
> > on a pxa27x to contact an on-board bluetooth adapter.  But AFAIK,
> > PDAs with an USB host _connector_ is pretty rare.  (There's a
> > CF/IO card adapter I've seen, but that's not quite the same.)
> 
> sl-5500 has peripheral controller, but sl-5600 and newer should have a
> host controller. [Unfortunately mine is 5500.]

I think you're wrong about all except possibly the very latest ones
using pxa27x chips.  The pxa25x based products would need a separate
controller chip to get host functionality.  I know for a fact that
even the C-860 doesn't have one integrated; folk use that CF/IO card,
with an sl811hs driver, if they crave a USB keyboard or flashdisk.

- Dave
 

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

Re: [RFC] Power Management Policies

[Pavel Machek]

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

Hi!

> > sl-5500 has peripheral controller, but sl-5600 and newer should have a
> > host controller. [Unfortunately mine is 5500.]
> 
> I think you're wrong about all except possibly the very latest ones
> using pxa27x chips.  The pxa25x based products would need a separate
> controller chip to get host functionality.  I know for a fact that
> even the C-860 doesn't have one integrated; folk use that CF/IO card,
> with an sl811hs driver, if they crave a USB keyboard or flashdisk.

I searched web a bit, on amazon pages:

Sharp Zaurus SL-6000L Handheld
Other products by Sharp

Usually ships within 1-2 business days


3 used & new from $799.00



Technical data

    * Operating System: Embedded Linux with J2ME CDC Personal Profile
    * Display: 4 inch 640 x 480 CG Silicon transflective TFT
    * Wireless: Integrated 802.11 lb
    * Keyboard: 37-key QWERTY keyboard with slide cover
    * Memory: 64 MB SDRAM; 64 MB Flash
    * Expansion Slots: 1 Type II CF slot; 1 SD slot
    * Input/Output: USB 1.1 host connector mini Type-A, IR port, 2.5
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Okay, that's strange. Mini conectors are only device-side, right?

If c-860 does not have usb, I was probably wrong (or confused by
something like above...)
								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Thursday 28 April 2005 11:59 am, Pavel Machek wrote:
> Hi!
> 
> > > sl-5500 has peripheral controller, but sl-5600 and newer should have a
> > > host controller. [Unfortunately mine is 5500.]
> > 
> > I think you're wrong about all except possibly the very latest ones
> > using pxa27x chips.  The pxa25x based products would need a separate
> > controller chip to get host functionality.  I know for a fact that
> > even the C-860 doesn't have one integrated; folk use that CF/IO card,
> > with an sl811hs driver, if they crave a USB keyboard or flashdisk.
> 
> I searched web a bit, on amazon pages:
> 
> Sharp Zaurus SL-6000L Handheld

That's sort of an exception, designed originally for IBM as I recall
and not originally as a "consumer" product.


> ...
>     * Input/Output: USB 1.1 host connector mini Type-A, IR port, 2.5
>                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Making me wonder what controller chip it uses ... or alternatively,
if that listing is wrong.  (It's been known to happen...)

> Okay, that's strange. Mini conectors are only device-side, right?

It's just a wee bit rare.  There are three kinds of USB "Mini"
sockets, used with "Mini-A" or "Mini-B" connectors on cables:

   - Mini-A, as above ... host only.  The Psion NetBook does this
     too (pxa 255 based, sl811hs host, no USB peripheral).  Used
     normally with an adapter, Mini-A to standard-A/socket, plus a
     more standard A-to-B cable like you'd use with a PC.

   - Mini-B, what you're thinking of ... peripheral only.  I've seen
     this on a variety of USB peripherals by now.   Cables normally
     go Mini-B to standard-A

   - Mini-AB, OTG-only ... you can connect either the Mini-A end
     of a cable into it, or the Mini-B end.  The device acts as
     either host or peripheral, as necessary.

I'd rather see OTG devices, with Mini-AB sockets, than Mini-A; but
OTG takes a while to adopt.


> If c-860 does not have usb, I was probably wrong (or confused by
> something like above...)

Just confused.  Mini-A is indeed not common.  C860 does have USB,
except it's the peripheral support (like most all PDAs I've seen).

- Dave

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

Re: [RFC] Power Management Policies

[Adam Belay]

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

On Mon, Apr 18, 2005 at 09:39:19AM -0600, Jordan Crouse wrote:

--> snip

> 
> > 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.  

I agree.

As a thought, what if we included some suggested power attribute
configurations as module data (much like we do with pci device IDs now)?
This  would allow the driver developer to pass this information up to
userspace, without imposing any policy.  The default settings could be
performance orriented and then when userspace starts up it could tell the
policy manager to slow things down.

In general, it seems to make sense for userspace to tell the kernel about
policy preferences, but then have the kernel execute those decisions.  If
we were to ship suggested policy options inside of driver modules, then 
driver developers could ensure the user is at least aware of typical policy
configuration values.

Also, it might be useful to distribute a set of userspace power management
tools. We could call it something like "hardware-utils" and have it handle PM
policy and other userspace driver core issues.

Thanks,
Adam

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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Saturday 23 April 2005 12:18 am, Adam Belay wrote:
> > > 
> > > 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.

Me too ...

> In general, it seems to make sense for userspace to tell the kernel about
> policy preferences, but then have the kernel execute those decisions.  If
> we were to ship suggested policy options inside of driver modules, then 
> driver developers could ensure the user is at least aware of typical policy
> configuration values.

The way I view things:  drivers offer choice-of-policy to userspace,
then userspace chooses the policy.

What I want to avoid is treating active userspace intervention as the
normal case ... polling every Nth-of-a-second as one example.  It's
quite reasonable for userspace to deal with higher level notions that
are already application-visible, like LCD (back)lighting or various
activity timeouts.  It's quite another thing to create interfaces
specifically to export low level monitoring to userspace.

- Dave

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

Re: [RFC] Power Management Policies

[David Brownell]

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

On Monday 18 April 2005 8:39 am, Jordan Crouse wrote:
>  [ open vs closed device/appliance models]
> 
> 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. 

There's product positioning ("marketing") involved here too.  Consumer
electronics models have traditionally been pretty "closed".  Putting
aside (temporarily) the issue that such models don't necessarily serve
the customers as well as they serve the manufacturers, it's also clear
that "open" systems are better for non-appliance/throwaway models.
They support add-on products and multi-vendor "eco"systems, where you
can get new features by add-ons rather than (expensive) replacements.

>From the customer point of view, the attraction of "closed" is limited.
It can be a huge win in terms of ease-of-use to not _need_ to configure
things, and know "this is how you do it".  Turn off brain, use product;
throw it away rather than repairing/upgrading.

I don't see major vendors wanting to move away from "closed" models
at the lower end, or in fact whereever they have the power to dictate
customer "preferences".  (The latter case is also known as a "market
failure", except by radical corporatists...)  But for higher end products,
or when customers truly have (or need!!) choices, then "open" is more
usually the answer.

- Dave


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

Re: Power Management Policies

[Jordan Crouse]

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

On 27/04/05 07:22 -0700, David Brownell wrote:
> I don't see major vendors wanting to move away from "closed" models
> at the lower end, or in fact whereever they have the power to dictate
> customer "preferences".  (The latter case is also known as a "market
> failure", except by radical corporatists...)  But for higher end products,
> or when customers truly have (or need!!) choices, then "open" is more
> usually the answer.

Indeed.  Really, my point was that massive userland based configuration is
better suited to systems with known configurations and vendors motivated to
spend the time and expense to tune the system.

As the system configuration opens up, it becomes less likely that the end user
will be willing to go to the same effort.  When you hit the desktop/laptop 
market, only the very uber of geeks will even consider it.

Which is why I think that userland tuning should be an option, and not
mandatory.  A wide majority of the users across the Linux spectrum might 
not care what the wake up latency of their NIC is, but I think that there are
enough that do to make a userland configuration framework useful.

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


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

Re: Re: Power Management Policies

[David Brownell]

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

On Wednesday 27 April 2005 7:57 am, Jordan Crouse wrote:
> On 27/04/05 07:22 -0700, David Brownell wrote:
> > I don't see major vendors wanting to move away from "closed" models
> > at the lower end, or in fact whereever they have the power to dictate
> > customer "preferences".  (The latter case is also known as a "market
> > failure", except by radical corporatists...)  But for higher end products,
> > or when customers truly have (or need!!) choices, then "open" is more
> > usually the answer.
> 
> Indeed.  Really, my point was that massive userland based configuration is
> better suited to systems with known configurations and vendors motivated to
> spend the time and expense to tune the system.

They _could_ apply some of that effort to in-kernel support, of course,.  :)
The question is what goes where.  Some folk talk about putting extremely low
level policies in userspace.  I'm more a fan of right-sizing/right-placing,
which means that a lot of hardware PM mechanisms won't show up in userspace.
(Except maybe for monitoring purposes, or as highlevel policy options.)


> ...
> Which is why I think that userland tuning should be an option, and not
> mandatory.  A wide majority of the users across the Linux spectrum might 
> not care what the wake up latency of their NIC is, but I think that there are
> enough that do to make a userland configuration framework useful.

Configuration framework, I agree.  Tuning, in the normal sense of
setting parameters and then going away, ditto.

There may even be a role for some "dynamic tuning", monitoring the
system and updating parameters on the fly to save power.  That's
sort of a grey zone though; such schemes can easily be abused.
I've maybe seen too many things fail because of broken userspace
policy implementations...

But there are things that don't belong in userspace, and IMO those
include many/most of the lowest level dirtiest bits of PM.  If userspace
sticks to policy selection, rather than implementing mechanism by
requiring the kernel to export low level hooks, I'll be happiest.

- Dave

 

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