Re: [PATCH] implement pm_ops.valid for everybody

David Brownell
2007-03-24T00:52:00Z

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
>