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

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

On Mon, May 24, 2010 at 09:34:54PM -0400, Alan Stern wrote:
> On Mon, 24 May 2010, Arve Hjønnevåg wrote:
> 
> > > Wakeup events can be lost in at least three different ways:
> > >
> > >     1. A hardware signal (such as an IRQ) gets ignored.
> > >
> > >     2. The hardware event occurs, but without effect since the
> > >        kernel thread that would handle the event has been frozen.
> > >        The event just ends up sitting in a queue somewhere until
> > >        something else wakes up the system.
> > >
> > >     3. The hardware event occurs and the kernel handles it fully,
> > >        but the event propagates to userspace for further handling
> > >        and the user program is already frozen.
> > >
> > > 1 is a hardware configuration failure (for example, it might happen as
> > > a result of using edge-triggered IRQs instead of level-triggered) and
> > > is outside the scope of this discussion.
> > >
> > > 2 generally represents a failure of the core PM subsystem, or a failure
> > > of some other part of the kernel to use the PM core correctly.  In
> > > theory we should be able to fix such mistakes.  Right now I'm aware of
> > > at least one possible failure scenario that could be fixed fairly
> > > easily.
> > >
> > > 3 is the type of failure that suspend blockers were really meant to
> > > handle, particularly the userspace suspend-blocker API.
> 
> > 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.

-- 
Dmitry