Messages in this thread | | | Date | Wed, 4 Aug 2010 13:51:59 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Attempted summary of suspend-blockers LKML thread |
| |
On Wed, Aug 04, 2010 at 10:42:08PM +0200, Pavel Machek wrote: > Hi! > > > > If this doesn't work for the Android folks for whatever reason, another > > > approach would be to do the freeze in user code, which could track > > > whether any user-level resources (pthread mutexes, SysV semas, whatever) > > > where held, and do the freeze on a thread-by-thread basis within each > > > "victim" application as the threads reach safe points. > > > > The main problem I see with the cgroups solution is that it doesn't seem > > to do anything to handle avoiding loss of wakeup events. > > In different message, Arve said they are actually using low-power idle > to emulate suspend on Android.
Hello, Pavel,
Could you please point me at this message?
Thanx, Paul
> This came like a bit of a shock to me ("why do they make it so complex > then"), but... it also means that as soon as you are able to stop > "unwanted" processing, you can just leave normal cpuidle mechanisms to > deal with the rest... > > (Of course, you'll also have to fix kernel timers not to beat > unneccessarily often; still that's better solution that just stoping > them all and then sprinkling wakelocks all over the kernel to deal > with obvious bugs it introduces...) > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |