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

[Arve Hjønnevåg]

2010/5/21 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
> On Fri, 21 May 2010, [UTF-8] Arve Hjønnevåg wrote:
>
>> The first goal can be achieved either by using device runtime PM and
>> cpuidle to put all hardware into low-power states, transparently from
>> the user space point of view, or by suspending the whole system.
>> However, system suspend, in its current form, does not guarantee that
>> the events of interest will always be responded to, since wakeup
>> events (events that wake the CPU from idle and the system from
>> suspend) that occur right after initiating suspend will not be
>> processed until another possibly unrelated event wakes the system up
>> again.
>
> Minor point of clarification here.  I'm not requesting that the patch
> description be rewritten.  But this issue of lost wakeup events is more
> subtle than it appears.
>
> 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.
>
> IMO, we should strive to fix the existing type-2 failure modes.
> However it is worth pointing out that they are basically separate from
> the suspend-blocker mechanism.
>
> And it might be a good idea to point out somewhere in the patch
> descriptions that suspend blockers are really meant to handle type-3
> wakeup losses.
>

I don't see a big difference between 2 and 3. You can use suspend
blockers to handle either.

-- 
Arve Hjønnevåg
--
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/