lkml.org 
[lkml]   [2010]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Thu, May 27, 2010 at 06:45:25PM +0200, Thomas Gleixner wrote:
    > On Thu, 27 May 2010, Matthew Garrett wrote:
    > > No. Suspend blockers are designed to ensure that suspend isn't racy with
    > > respect to wakeup events. The bit that mitigates badly written
    > > applications is the bit where the scheduler doesn't run any more.
    > >
    > > If you're happy with a single badly written application being able to
    > > cripple your power management story, you don't need opportunistic
    > > suspend. But you still have complications when it comes to deciding to
    > > enter suspend at the same time as you receive a wakeup event.
    >
    > Wrong. Setting the QoS requirements of the badly written app to any
    > latency will allow the kernel to suspend even if the crappy app is
    > active.

    That's not what I want if I'm using the app at the time...

    > And again. I'm opposing the general chant that fixing crappy
    > applications in the kernel is a good thing. It's the worst decision we
    > could make.

    You still need the in-kernel suspend blockers if you want to guarantee
    that you can't lose wakeup events. But yes, if you're not concerned
    handling badly behaved applications then I believe that you can lose
    opportunistic suspend and just use the scheduler.

    > The whole notion of treating suspend to RAM any different than a plain
    > idle C-State is wrong. It's not different at all. You just use a
    > different mechanism which has longer takedown and wakeup latencies and
    > requires to shut down stuff and setup extra wakeup sources.

    My question was about explicit suspend states, not implicitly handling
    an identical state based on scheduler constraints. Suspend-as-a-C-state
    isn't usable on x86 - you have to explicitly trigger it based on some
    policy. And if you want to be able to do that without risking the loss
    of wakeup events then you need in-kernel suspend blockers.

    > I'm starting to get really grumpy about the chant that suspend
    > blockers are the only way to fix missed wakeups. That might be the
    > only way you can think of with your pink android glasses on, but again
    > this is not rocket science even if it does not fit into the current
    > way the kernel handles the whole suspend mechanism.

    I don't work for Google. I'm not an Android developer.

    > So if we really sit back and look at suspend as another idle state,
    > then we have first off the same requirements for entering it as we
    > have for any other idle state:

    There are various platforms where we cannot treat suspend as an idle
    state. Any solution that requires that doesn't actually solve the
    problem. Yes, this is *trivial* if you can depend on the scheduler. But
    we can't, and so it's difficult.

    --
    Matthew Garrett | mjg59@srcf.ucam.org


    \
     
     \ /
      Last update: 2010-05-27 19:03    [W:4.048 / U:1.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site