On Thu, 5 Aug 2010 07:33:59 +0200 Florian Mickler <florian@xxxxxxxxxxx> wrote: > On Wed, 4 Aug 2010 16:10:03 -0700 > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > > No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle > is used. For idle decision a certain subset of tasks is ignored. > > Where suspend is prevented by the trusted > process in android-world taking a wakelock, here it would just prevent > the system from going idle by arming timers. > > This would be pretty equivalent to the suspend-blocker scheme and not > introduce new userspace api. But the downside is, as Arve pointed out, > that now one can not get full-idle-power-leverage while suspend > is blocked. > > [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and > following > > > Cheers, > Flo > There are a few downsides that got mentioned already in reponse.. I got a little lagged behind. There are upsides to this approach like not having a special purpose userspace api, conceptually integrating suspend into the idle mechanism .. Short summary of the cons that got mentioned: - applications need to resort to polling to keep the system out of idle (-> system will never be fully idle) - the race between deciding to suspend and becoming active again is not handled - no special statistics available - the timers of the ignored applications will behave unexpected (as the monotonic clock is not stopped)... while applications have already to cope with network-loss, other side effects of suspend without monotonic clock stopped are to be expected... Cheers, Flo _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
