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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, May 25, 2010 at 09:47:22PM +0200, Rafael J. Wysocki wrote:
> On Tuesday 25 May 2010, Dmitry Torokhov wrote:
> > On Tuesday 25 May 2010 11:08:03 am Alan Stern wrote:
> > > On Tue, 25 May 2010, Dmitry Torokhov wrote:
> > > > > > I don't see a big difference between 2 and 3. You can use suspend
> > > > > > blockers to handle either.
> > > > > 
> > > > > You can, but they aren't necessary.  If 2 were the only reason for
> > > > > suspend blockers, I would say they shouldn't be merged.
> > > > > 
> > > > > Whereas 3, on the other hand, can _not_ be handled by any existing
> > > > > mechanism.  3 is perhaps the most important reason for using suspend
> > > > > blockers.
> > > > 
> > > > I do not see why 3 has to be implemented using suspend blockers either.
> > > > If you are concerned that event gets stuck somewhere in the stack make
> > > > sure that devices in the stack do not suspend while their queue is not
> > > > empty. This way if you try opportunistic suspend it will keep failing
> > > > until you drained all important queues.
> > > 
> > > Here's the scenario:
> > > 
> > > The system is awake, and the user presses a key. The keyboard driver
> > > processes the keystroke and puts it in an input queue.  A user process
> > > reads it from the event queue, thereby emptying the queue.
> > > 
> > > At that moment, the system decides to go into opportunistic suspend.
> > > Since the input queue is empty, there's nothing to stop it.  As the
> > > first step, userspace is frozen -- before the process has a chance to
> > > do anything with the keystroke it just read.  As a result, the system
> > > stays asleep until something else wakes it up, even though the
> > > keystroke was important and should have prevented it from sleeping.
> > > 
> > > Suspend blockers protect against this scenario.  Here's how:
> > > 
> > > The user process doesn't read the input queue directly; instead it
> > > does a select or poll.  When it sees there is data in the queue, it
> > > first acquires a suspend blocker and then reads the data.
> > > 
> > > Now the system _can't_ go into opportunistic suspend, because a suspend
> > > blocker is active.  The user process can do whatever it wants with the
> > > keystroke.  When it is finished, it releases the suspend blocker and
> > > loops back to the select/poll call.
> > > 
> > 
> > What you describe can be done in userspace though, via a "suspend manager" 
> > process. Tasks reading input events will post "busy" events to stop the 
> > manager process from sending system into suspend. But this can be confined to 
> > Android userspace, leaving the kernel as is (well, kernel needs to be modified 
> > to not go into suspend with full queues, but that is using existing kernel 
> > APIs).
> 
> For that to work, you'd have to make the user space suspend manager prevent
> key-reading processes from emptying the queue before it orders the kernel to
> put the system to sleep.  Otherwise it still is possible that the queue will be
> emptied right at the moment it writes to /sys/power/state and the scenario
> described by Alan is going to happen.
>

You do exactly the same as what Alan done, but in userspace - poll, post
"busy" event to suspend manager, read, process, retract "busy".
Basically you still have the suspend blocker, but it is confined to your
userspace.

> Moreover, I don't think it's limited to the input subsystem, because the wakeup
> events may originate from the network or some other sources and all of them
> would require similar handling.

Yes, all devices (real or virtual), not only input ones, holding the
queues have to refuse suspending for this to work.

> 
> The problem here is that user space can't do anything to stop the freezing of
> tasks without suspend blockers (or something more-or-less equivalent).

Sure it can if suspend is intiated by userspace itself.

-- 
Dmitry