[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.300 / U:33.376 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site