Re: Attempted summary of suspend-blockers LKML thread

[david]

On Wed, 4 Aug 2010, Florian Mickler wrote:

> Subject: Re: Attempted summary of suspend-blockers LKML thread
>
> On Tue, 3 Aug 2010 21:55:07 -0700 (PDT)
> david@xxxxxxx wrote:
>
> > On Tue, 3 Aug 2010, Arjan van de Ven wrote:
> >
> > > On Tue, 3 Aug 2010 17:10:15 -0700
> > > "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> > > > OK, I'll bite...
> > > >
> > > > > From an Android perspective, the differences are as follows:
> > > >
> > > > 1.	Deep idle states are entered only if there are no runnable
> > > > tasks. In contrast, opportunistic suspend can happen even when there
> > > > 	are tasks that are ready, willing, and able to run.
> > >
> > > for "system suspend", this is an absolutely valid statement.
> > > for "use suspend as idle state", it's not so clearly valid.
> > > (but this is sort of a separate problem, basically the "when do we
> > > freeze the tasks that we don't like for power reasons" problem,
> > > which in first order is independent on what kind of idle power state
> > > you pick, and discussed extensively elsewhere in this thread)
> >
> > note that what I'm speculating about would never freeze some of the tasks,
> > it would run everything if anything is run, but it would not consider the
> > actions of some of the programs when deciding if it can shutdown.
> >
> > so if you have all your privilaged applications in long sleeps, but still
> > have your bouncing cows running, peggng the CPU, making noise, and
> > updating the screen, the system would decide the system is 'idle' and go
> > into the 'suspend' low power state until there is a wake activity.
> >
> > but if you have a privilaged application doing other stuff (say you are
> > talking on the phone, have a GPS mapping program running and giving you
> > directions, etc), the bouncing cows would continue to run and there would
> > never be an attempt to freeze them while leaving the other stuff active.
> >
> > David Lang
>
> I think the only difference between your proposition and the
> current android practice is that in your scheme the partition is along
> the process/task boundary (i.e. good apps vs bad apps) whereas the
> android looks at actions or events or ... let's call it "stuff" and
> blocks suspend whenever "stuff" needs to be done.

with the caviot that only privilaged applications are allowed to define 
that "stuff" needs to be done

> The main thing is that even an process that is allowed to block suspend
> doesn't do so all the time. Only when it is critical that "stuff" get's
> done right away.

effectivly, only when it's important that "stuff" gets done at all. With 
current smartphone battery capacities it's not uncommon that the phone 
could be in suspend until the battery dies, since suspend is not zero 
power.

> One way to make an application work the same way with your scheme (as
> I understand it) on android could be to split the
> application into an "blocker" part, that is not part of the
> "ignore-cgroup" (the "trusted" part) and another one that is in the
> "ignore-cgroup" (the "untrusted" part). Whenever the untrusted part
> needs to block suspend it notices the "trusted" part via ipc and the
> trusted part goes into some sort of "activity loop". This looks kind of
> stupid. But I bet it is what application developers are going to do if
> there is no provision for a flexible runtime enable/disable "suspend
> blocker".

remember that only "trusted" applications were allowed to set the 
suspend-blocker/wakelock flag in the first place.

my thinking is that since "trusted" applications are assumed to be well 
written (or they can just raise the suspend-blocker/wakelock and keep the 
phone from ever sleeping) they should be able to be trusted to sleep 
appropriately so that if they aren't actually doing anything important the 
system can go ahead and go to sleep.

Since powertop was designed to find ill-bahaved applications, you would 
still be able to point the finger at the offenders.


yes, you could trivially have a 'keep me awake' daemon that other apps can 
talk to to request the system stay awake (the same way you could with a 
suspend-blocker/wakelock). The "activity loop" for such a 
daemon can be pretty trivial, set a timer just a little shorter than the 
idle-go-to-suspend timeout, sleep that long and reset the timer.

I could be mistaken here, but my assumption is that since normal 
applications running would never get trigger the wakelock except when 
there is user input, the timeout here is on the order of 10s of seconds, 
if not a few minutes. having a privilaged application wake up once every 
several seconds is not going to be significant to anything other than 
things looking for the system being idle for X amount of time..

Even if this is done, having a userspace 'wakelock' daemon that works this 
way is significantly better in many people's eyes than having the kernel 
implement this policy. It's much easier to put application/platform 
specific logic in the userspace daemon than into the kernel (say, things 
like 'any app can request a delay for up to X amount of time, but after 
that they cannot request it again for Y amount of time, except ....)


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/