[lkml]   [2010]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler <> wrote:
    > On Sat, 5 Jun 2010 20:44:24 +0300
    > Felipe Contreras <> wrote:
    >> 2010/6/2 Arve Hjønnevåg <>:
    >> > 2010/6/2 Peter Zijlstra <>:
    >> >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
    >> >> fixing it, get over it already).
    >> >>
    >> >
    >> > I don't think it is realistic to drop support for all existing hardware.
    >> We are talking about mainline here, there's no support for suspend
    >> blockers, so nothing is dropped.
    >> In the mind of everybody, suspend blockers is for opportunistic
    >> suspend, which only makes sense on sensible hw (not current x86). So
    >> in the mind of everybody, x86 should be out of scope for the analysis
    >> of suspend blockers.
    >> Are you seriously suggesting that one of the strong arguments in favor
    >> of suspend blockers is x86 usage (nobody agrees)? If not, then drop
    >> it.
    > I think they have an advantage over the
    > 30-minute-screensaver-then-suspend that current desktops do. Because
    > you can define what keeps the system up. I.e. the
    > screensaver/powermanager is not limited to keyboard- and
    > mouse-inactivity.

    What prevents you from defining other things keeping the system up
    right now? Nothing. It's up to user-space to decide when to suspend.
    In fact applications already block suspend; Transmission has the
    option to block suspend when downloading torrents.

    >> If I enable suspend blockers on my laptop, I have to modify my
    >> user-space. Otherwise my system will behave horribly.
    > In the simplest case you have a shell script which takes a suspend
    > blocker and reads from stdinput. When you write "mem" to it, it
    > releases the suspend blocker and acquires it back again. Voila, forced
    > suspend reimplemented on top of opportunistic suspend.
    > That wasn't hard, was it?

    Not hard, but still a modification of user-space, and a pretty bad one
    because it will prevent typical forced suspend, and typical suspend
    delaying (like with Transmission). Supposing the opportunistic suspend
    doesn't block the forced suspend, still, absolutely nothing will be
    achieved by enabling suspend blockers.

    If you want to take even a minimal advantage of suspend blockers you
    need serious modifications to user-space.

    Supposing there's a perfect usage of suspend blockers from user-space
    on current x86 platforms (in theory Android would have that), is the
    benefit that big to consider this a strong argument in favor of
    suspend blockers? Considering the small amount of x86 platforms using
    Android (is there any?), the fact that nobody else will use suspend
    blockers, and that x86 is already being fixed (as mentioned many times
    before) so dynamic PM is possible, I don't think we should be
    considering current x86 at all for suspend blockers.

    Felipe Contreras
    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-06-05 22:31    [W:0.025 / U:21.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site