lkml.org 
[lkml]   [2010]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    From
    2010/8/4  <david@lang.hm>:
    > On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
    >
    >> On Wed, Aug 4, 2010 at 3:31 PM,  <david@lang.hm> wrote:
    >>>
    >>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
    >>>
    >>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
    >>>>>
    >>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
    >>>>>>
    >>>>>> No! And that's precisely the issue. Android's existing behaviour could
    >>>>>> be entirely implemented in the form of binary that manually triggers
    >>>>>> suspend when (a) the screen is off and (b) no userspace applications
    >>>>>> have indicated that the system shouldn't sleep, except for the wakeup
    >>>>>> event race. Imagine the following:
    >>>>>>
    >>>>>> 1) The policy timeout is about to expire. No applications are holding
    >>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
    >>>>>> 2) A network packet arrives indicating an incoming SIP call
    >>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
    >>>>>> suspending while the call is in progress
    >>>>>>
    >>>>>> What stops the system going to sleep between (2) and (3)? cgroups
    >>>>>> don't,
    >>>>>> because the voip app is an otherwise untrusted application that you've
    >>>>>> just told the scheduler to ignore.
    >>>>>
    >>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
    >>>>> to
    >>>>> avoid the race (if pm_wakeup_event() is called at 2)).
    >>>>
    >>>> Yes, I think that solves the problem. The only question then is whether
    >>>> it's preferable to use cgroups or suspend fully, which is pretty much up
    >>>> to the implementation. In other words, is there a reason we're still
    >>>> having this conversation? :) It'd be good to have some feedback from
    >>>> Google as to whether this satisfies their functional requirements.
    >>>
    >>> the proposal that I nade was not to use cgroups to freeze some processes
    >>> and
    >>> not others, but to use cgroups to decide to ignore some processes when
    >>> deciding if the system is idle, stop everything or nothing. cgroups are
    >>> just
    >>> a way of easily grouping processes (and their children) into different
    >>> groups.
    >>>
    >>
    >> That does not avoid the dependency problem. A process may be waiting
    >> on a resource that a process you ignore owns. I you ignore the process
    >> that owns the resource and enter idle when it is ready to run (or
    >> waiting on a timer), you are still effectively blocking the other
    >> process.
    >
    > and if you don't have a wakelock the same thing will happen. If you expect

    Not the same thing. If you don't hold a wakelock the entire system
    will suspend and when it wakes up it continues where it left off.
    Timeout still have time left before they expire.

    > the process to take a while you can set a timeout to wake up every 30
    > seconds or so and wait again, this would be enough to prevent you from going

    I don't think polling is an acceptable solution to this problem. You
    user space code know needs to know what "idle" timeout you have
    selected so it can choose a faster poll rate. When is it safe to stop
    polling?

    > to sleep (or am I misunderstanding how long before you go into suspend
    > without a wakelock set, see my other e-mail for the full question)
    >

    We suspend as soon as no wakelocks are held. There is no delay.

    --
    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-08-05 01:17    [W:2.487 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site