[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, 25 May 2010, Dmitry Torokhov wrote:

> > How is that not polling? If the user is holding down a key, the keypad
> > driver has to block suspend, and user space will try to suspend again
> > and again and again...
> >
> If your userpsace is that stupid - sure. However, you can:
> 1. Notify the suspend manager process that he rest of your userspace is
> busy handling keystrokes so that it does not try to suspend while there
> are events pending.
> 2. Wait a tiny bit after last application notified you that it finished
> processing events.

This is more complicated than necessary. Arve is wrong; my suggested
design does not require polling.

The reason is simple: When a user process initiates an opportunistic
suspend, you make it wait in an interruptible sleep until all the
kernel suspend blockers are released. No polling. If another user
thread decides in the meantime that it needs to block the suspend, it
sends a signal to the power manager process.

In fact, other threads should signal the power manager process whenever
they want to block or unblock suspends. That way the power manager
process can spend all its time sleeping, without doing any polling.

> So basically the difference is that with in-kernel suspend blockers,
> there is a tiny window where we haven't started the suspend yet but are
> about to the driver has a chance to prevent entire system from starting
> sleep.
> Without the blocker we may start suspending and will stop midcycle. We
> may be even better off in the end since we could leave some devices
> still powered down after aborting system-wide suspend.

That's not so easy. The design of the PM core requires that when the
system wakes up from suspend (or from an aborted suspend attempt), all
devices should go to full-power-on. This is explained in section 6 of

The decision over whether to use kernel-space suspend blockers vs.
aborting suspends when queues are non-empty comes down to a tradeoff:

Suspend blockers involve a little more code (to create,
destroy, enable, and disable them) plus a little extra
runtime overhead each time an event occurs. (Some people
may object to this extra overhead, although so far nobody
in this discussion has done so.)

Suspend blockers eliminate the extra overhead involved in
starting suspends that are just going to be aborted.

Suspend blockers offer extra debugging and accountability
(the user can find out which subsystems are responsible for
keeping the system awake).

Which way you think the tradeoff should go is a subjective decision. I
think that kernel suspend blockers are acceptable.

Alan Stern

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