Re: [PATCH 1/8] PM: Add suspend block api.

Tony Lindgren
2010-05-07T19:55:48Z

* Matthew Garrett <mjg@redhat.com> [100507 12:29]:
> On Fri, May 07, 2010 at 12:28:37PM -0700, Tony Lindgren wrote:
> > * Daniel Walker <dwalker@fifo99.com> [100507 12:01]:
> > > On Fri, 2010-05-07 at 19:46 +0100, Matthew Garrett wrote:
> > > > Freezer cgroups would work better, but it doesn't really change the
> > > > point - if that application has an open network socket, how do you know
> > > > to resume that application when a packet comes in?
> >
> > No idea, but that still sounds a better situation to me than
> > trying to deal with that for a suspended system! :)
>
> Suspend blocks deal with that problem. Nobody has yet demonstrated a
> workable alternative solution.

Well there are obviously two paths to take, I think both of
them should work. The alternative to suspend blockers is:

- Implement a decent kernel idle function for the hardware and
use cpuidle to change the c states. The dyntick stuff should
already work for most hardware.

- Fix the core userspace apps to minimize timers.

- Deal with broken apps whichever way you want in the userspace.

- Optionally, do echo mem > /sys/power/state based on some
product specific logic in the userspace.

The advantage of this is that no kernel changes are needed,
except for implementing the custom idle function for the
hardware. And this kind of setup has been in use for about
five years.

And, you can keep the system running constantly if you have
hardware that supports good idle modes, then you don't even
need to suspend at all.

The core problems I see with suspend blockers are following,
please correct me if I'm wrong:

- It is caching the value of echo mem > /sys/power/state and
misusing it for runtime power management as the system still
keeps running after trying to suspend. Instead, the kernel
idle function and cpuidle should be used if the kernel keeps
running.

- They require patching all over the drivers and userspace.

- Once the system is suspended, it does not run. And the apps
don't behave in a standard way because the system does not
wake to timer interrupts.

I agree that we need to be able to echo mem > /sys/power/state
in an atomic way. So if there are problems with that, those
issues should be fixed.

Cheers,

Tony