[lkml]   [2010]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
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

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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2010-05-26 10:45    [W:0.426 / U:8.096 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site