[lkml]   [2010]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
    2010/5/21 Alan Stern <>:
    > 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-05-25 03:07    [W:0.023 / U:6.196 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site