Re: [PATCH] implement pm_ops.valid for everybody

[David Brownell <david-b@pacbell.net>]

On Friday 23 March 2007 2:08 pm, Guennadi Liakhovetski wrote:
> On Fri, 23 Mar 2007, David Brownell wrote:
> > 
> > Yuck.  No.  Speed is only a factor in that STR is likely slower.
> 
> I'm just trying to think about it from the user perspective. As a user I 
> want - save the system save some power but be ready again when I need it 
> _not_ _later_ than, 10 sec after wakeup. I don't care how it is called. I 
> want to save as much power as possible and I want a certain wakeup time. 

That's not really a kernel issue; and it's highly dependent on what
devices are hooked up.  What if certain devices take a second to
re-activate ... and you have a dozen of them hooked up?


> Yes, if one system in your example is clocked slower, then yes, saying "I 
> want it back up and running 5 seconds after wakeup" will for one of them 
> mean "standby" for another one "str". As a user I don't care whatsoever 
> what PCI state you drive my eth card into. I want it back in 5 seconds.

I don't think any of the current tools address such guarantees.

And it seems to me you're looking at this more from a tools
perspective than from "what does pm_ops.enter(STATE) do".
So this is a change-of-topic.


> Similarly for single devices: I don't need wlan now, but when I need it I 
> want it to be available in less than 2 seconds.

That's a driver-specific issue.


> And if I say 10 minutes hibernate it.

The tools I've seen give a "hibernate" (suspend-to-disk) option,
but not a "10 minutes" option ... and on Linux, there isn't even
any kind of "enter system state X if idle for M minutes" facility.


> If I say "don't care about time, save maximum power" - similarly.

Again, that's an issue about what some to-be-written userspace
tool might do.


> And I may say "I want it wakeable from eth" or "from modem" take that into 
> account too.

All those are driver configuration issues, although there's also
a huge dose of "ACPI wake events rarely work".  For ethernet
devices there's "ethtool".  For serial lines and other devices,
there's /sys/devices/.../power/wakeup configuration.

 
> Those would be policies to be implemented in the user space. The kernel 
> might just present a single numerical per-device parameter "wakeup 
> responsiveness", and a way to do this system-wide.

Today, if you want to associate a set of wakeup events with some
particular sleep state (and the hardware supports them), just update
the /sys/devices/.../power/wakeup values before writing /sys/power/state
and voila!

That could be done with a shell script.

- Dave


> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
>