On Thu, 5 Aug 2010, Florian Mickler wrote: > 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 .. first off, a good summary of that I've been saying, thanks. > 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) true, although the power difference between a system that is completelyidle (but with a wavelock held) and a system where one application is polling every 10 seconds or so is _really_ low. > - the race between deciding to suspend and becoming active > again is not handled this one I will admit to not fully understanding, it sounds like there are opptions here, but I don't understand them or their trade-offs > - no special statistics available or no special statistics needed. Powertop is already avaible to analyse a system and report what processes are keeping it awake. Why would this not be enough? > - 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... I'm not sure this is true. there's nothing stopping the suspend (when it finally does happen) from stopping the monotonic clock. The core of my proposal is tweaking how we decide to suspend. Other than the possibility that we decide to suspend between timers (and set an alarm to wake up when a timer would go off) I'm not suggesting that the suspend itself change once it's finally triggered. David Lang _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
