Messages in this thread | | | Date | Thu, 5 Aug 2010 07:56:29 +0200 | From | Florian Mickler <> | Subject | Re: Attempted summary of suspend-blockers LKML thread |
| |
On Thu, 5 Aug 2010 07:33:59 +0200 Florian Mickler <florian@mickler.org> wrote:
> On Wed, 4 Aug 2010 16:10:03 -0700 > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> 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
| |