[lkml]   [2009]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFD] Automatic suspend

    > > Arve said that the power state was equivalent in idle and suspend, but
    > > that they preferred suspend because it stopped any periodic timers. I'd
    > > be more interested in making sure that unnecessary timers aren't running
    > > than focusing on automatically entering system-wide suspend - Nokia have
    > > been managing this since 2005 with good results.
    > We'd totally agree that doing something about periodic timers would be a
    > big win. There's also the situation that the longest ARM linux can sit
    > in idle right now is ~2s at a time (Arve can expand on the exact issue
    > relating to a 32bit signed nanosecond value somewhere iirc), which we'd
    > want to sort out as well.
    > Of course that still doesn't address userspace. Aggressively going to
    > suspend lets us compensate for userspace programs that do somewhat silly
    > things (I agree that it would be best if they didn't but they do and
    > getting *everyone* to write their userspace code to avoid spinning or
    > avoid waking up on short-duration timers to poll is a losing battle).

    Well, really? AFAICS, we can either

    1) Android solution: let the polling code live, and modify everyone
    that _really_ wants to run to use wakelocks.

    2) Solution proposed here: fix the polling code.

    IMNSHO 1) means modifying many applications, too... See android
    marked, 50%+ apps request "keep system woke up" capability. Plus it
    means modifying _good_ code, and leaving _bad_ code unfixed. So I'd
    prefer 2). I believe ammount of work is pretty similar.

    (cesky, pictures)

     \ /
      Last update: 2009-02-27 11:01    [W:0.026 / U:59.548 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site