Re: [PATCH 1/8] PM: Opportunistic suspend support.

[Peter Zijlstra]

On Tue, 2010-05-25 at 15:33 -0700, Arve HjÃnnevÃg wrote:
> The biggest problem here is not that it is hard to change our
> user-space, but that the proposed change is inferior to what we have
> now. It forces us to poll until all drivers stop aborting suspend. On
> one hand we have people telling us that all code that polls is broken
> and must be fixed (instead of suspending to limit the damage), and on
> the other hand we have people suggesting we implement opportunistic
> suspend by polling from user-space until suspend succeeds. 

No it does _not_. You're really not getting that Dmitry is proposing.


So your proposal is that when we wake userspace, it
opens /dev/suspend_blocker _before_ it consumes whatever event, consumes
the event, deals with the event, then closes the suspend_blocker. Then
the kernel, upon reaching a 0 suspend_blocker count, will try to suspend
again.


What Dmitry proposes is that, the app _before_ it consumes the event,
pokes at this suspend manager, it increases a blocker count, then
consumes the event (the kernel will _not_ auto-suspend), handles it and
then again pokes the suspend manager, this time decreasing the blocker
count.

The suspend manager will, upon reaching a 0 block count, suspend the
machine. If that fails, it means there's something to do, an app will
inc, work, dec its count, and it will try again once it reaches 0 again.

There is no polling what-so-ever in this model.

The only thing is that the kernel will not try to auto-suspend and there
is no user-space suspend blocker API.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/