Hi! > > 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. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
