lkml.org 
[lkml]   [2010]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: resume latency QoS support, unify suspend/resume into idle states
    From
    On Fri, May 28, 2010 at 2:21 AM, Ingo Molnar <mingo@elte.hu> wrote:
    >
    > * Arve Hj?nnev?g <arve@android.com> wrote:
    >
    >> On Thu, May 27, 2010 at 3:23 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
    >> > On Thu, 27 May 2010 23:09:49 +0100
    >> > Matthew Garrett <mjg59@srcf.ucam.org> wrote:
    >> >
    >> >> On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
    >> >>
    >> >> > This is I believe robust (and has been implemented on some non x86
    >> >> > boxes). It depends on not forcing running tasks into suspend. That is the
    >> >> > key.
    >> >>
    >> >> We've already established that ACPI systems require us to force running
    >> >> tasks into suspend. How do we avoid the race in that situation?
    >> >
    >> > Android phones do not have ACPI. Embedded platforms do not have ACPI. MID
    >> > x86 devices do not have ACPI.
    >>
    >> Android does not only run on phones. It is possible that no android devices
    >> have ACPI, but I don't know that for a fact. What I do know is that people
    >> want to run Android on x86 hardware and supporting suspend could be very
    >> benficial.
    >
    > (If there's a sane framework then we'll fix x86 to fit into it and will deal
    > with quirks.)
    >
    >> > I would imagine the existing laptops will handle power management limited
    >> > by the functionality they have available. Just like any other piece of
    >> > hardware.
    >>
    >> I think existing laptops (and desktops) can benefit from opportunistic
    >> suspend support. If opportunistic suspend is used for auto-sleep after
    >> inactivity instead of forced suspend, the user space suspend blocker api
    >> will allow an application to delay this auto sleep until for instance a
    >> download completes. This part could also be done with a user-space IPC call,
    >> but having a standard kernel interface for it may make it more common. A
    >> less common case, but more critical, is RTC alarms. I know my desktops can
    >> wakeup at a specific time by programming an RTC alarm, but without suspend
    >> blockers how do you ensure that the system does not suspend right after the
    >> alarm triggered? I have a system that wakes up at specific times requested
    >> by my DVR application, but I cannot use this system for anything else unless
    >> I manually turn off the DVR application's auto-sleep feature. With suspend
    >> blockers and something like the android alarm driver, I could use this
    >> system for more than one application that have scheduled tasks and it would
    >> be more usable for interactive applications.
    >
    > I really like the level of detail and care that went into suspend-blockers,
    > and i think the Android solution is very mature in terms of functionality
    > offered to users.
    >
    > In terms of bringing this depth of functionality and control to the upstream
    > kernel, what do you think about Alan's QoS scheme, described in:
    >
    >   <20100528001514.28e593ef@lxorguk.ukuu.org.uk>
    >
    > ?
    >
    > It's in essence suspend-blockers on steroids. It consists of two main
    > components:
    >
    >  - Unify the 'suspended' state into the regular chain of idle states, and
    >   create a single, coherent and transparent way we handle system idleness.
    >
    >  - Give apps a QoS attribute that allows them to express how long they can
    >   afford to wait for a wakeup. (A downloading app would set it to say 50msecs,
    >   and thus the kernel would know it automatically which method of idleness is
    >   still achievable. If all currently running apps have a max(QoS) attribute
    >   of infinite, then the kernel can suspend for an unlimited amount of time.)
    >
    > AFAICS, and i have read through your suspend-blocker usecases, this should
    > handle all the usecases you listed - and some more. (please yell if that's not
    > so)
    >
    > Suspend-blockers are equivalent to: 'app sets idle QoS latency to 0 msecs'.
    >
    > (And on x86, for BIOS/CPU combos that allow it we can implement this scheme
    > too.)
    >
    > Thoughts?

    Tying the QoS attribute to apps does not work (all proposals I have
    seen have race conditions), but replacing every suspend blocker with
    unique QoS object will work, since is the same thing as what suspend
    blockers provide. I think replacing suspend blockers with artificial
    latency requirements is a bad idea though, since we use them to ensure
    a specific level of functionality (tasks, timers and interrupts
    operate normally). If we get a more generic constraint framework,
    suspend blockers may possibly be absorbed by this, but I think the
    current implementation is useful as is (it could even be useful to
    someone working on a generic constraints framework).

    --
    Arve Hjønnevåg
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-05-28 12:01    [W:0.032 / U:1.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site