From: Alan Stern on
On Fri, 28 May 2010, Peter Zijlstra wrote:

> It seems most of the problems the suspend-blockers are trying to solve
> are due to the fact of not running runnable tasks.

That is only partially correct.

If Android were using idle-time PM and not forced suspend, then yes --
not running runnable tasks would be a big problem.

But as it stands, with forced suspend the problem is to avoid delays in
processing wakeup events. That's what suspend blockers are meant to
solve. The same problem would occur with idle-time PM if you don't run
all runnable tasks, and it would need a similar solution.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
On Fri, 28 May 2010 15:02:37 +0100
> Ok, I think I've misunderstood you. You're actually saying that only
> applications that are trusted to behave well are allowed to receive
> wakeup events? Yes, that makes implementation significantly easier. If

To receive them in a manner that they are permitted to defer a suspend.
There is non reason why bouncing cows shouldn't get to see an event, but
there is always the miniscule possibility that we choose to suspend as it
gets the event.

That to me seems fine. Our starting basis was

- Bouncing cows is not trusted

Android's reaction was

- We reserve the right to suspend bouncing cows where it likes it or not

The caveat becomes

- Bouncing cows may get suspended then get an event when the phone wakes
back up. So I might press "Moo" just before a suspend and get the noise
when it resumes.

Given the untrusted cows could respond to the event otherwise by blocking
the suspend for as long as permitted with a suspend blocker or similar
that seems no worse. In this case probably better [oof zap! as opposed to
60 seconds of 'event, no sorry got a cow to draw at 100% CPU')

As the app is untrusted we can't assume they would get suspend blockers
right even if they had any.

You can still be nice to the cows app and when the phone is put down send
it a 10 second warning via dbus or Android equivalents.

Your trusted call handling app can still request (by QoS or big hammers)
that the phone does not suspend even if the app goes idle (because you
have a wakeup latency QoS)

A na�ve trusted app will behave according to power management idling to
suspend and get stopped

A na�ve untrusted app that is doing sane things will spend most of its
life asleep and behave.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Fri, 2010-05-28 at 10:35 -0400, Alan Stern wrote:
> The app is busy doing something else unimportant
> We do into power save
> Push a button, generate an IRQ
> Come out of power save
> No app to poke
> * System goes back to sleep and eventually wakes up again
> The app finishes what it was doing
> The app sees there is a keystroke and marks itself important
> ...
>
> The * step is where trouble can occur.

Only because you don't run runnable tasks. Please stop considering that
an option and these problems go away.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on
On Fri, May 28, 2010 at 8:06 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote:
>> Arve points out that qos constraint objects could work (but not if
>> specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
>> he suggests that "latency" constraints don't represent this as well as
>> "state" constraints.
>
> With latency you have an "I don't give damn" latency in your model which
> we could describe as infinite or "manyana" perhaps.

I think Arve's concern was the representation of the "I care, but only
a little" or "just low enough to ensure threads must run" level which
is what suspend blockers would map to (low enough to ensure we
shouldn't halt the world but not necessarily implying a hard latency
constraint beyond that).

>> Though if you look at it that way, then suspend_blockers become qos
>> constraint objects, but their implementation and usage remain pretty
>> much the same as we have now, which does not address Alan's concern
>> regarding code turning up in drivers, etc.  I'm not sure how you can
>> solve this problem (avoiding races around entering/exiting the suspend
>> or suspend-like state) without having a means for drivers to prevent
>> entry to that state.
>
> I am much much less concerned about general expressions of constraint
> appearing in drivers. One of my early mails gave a list of other
> people/projects/problems that need them - from hard real time, to high
> speed serial on low end embedded to virtualisation.
>
> They fix a general problem in terms of a driver specific item. We end up
> making changes around the tree but we make everyone happy not just
> Android. Also we are isolating policy properly. The apps and drivers say
> "I have these needs", the power manager figures out how to meet them.

That makes sense -- and as I've mentioned elsewhere, we're really not
super picky about naming -- if it turns out that
wakelocks/suspendblockers were shorthand for "request a qos constraint
that ensures that threads are running", we'll be able to get things
done just as well as we do now.

> Where it gets ugly is if you start trying to have drivers giving an app a
> guarantee which the app then magically has to know to dispose of.

Yeah -- which is something we've avoided in the existing model with
overlapping wakelocks during handoff between domains.
- input service is select()ing on input devices
- when select() returns it grabs a wakelock, reads events, passes them
on, releases the wakelock
- the event subsystem can then safely drop its "should be running
threads" constraint as soon as the last event is read because it has
no queues for userspace to drain, but the overlapping wakelock
prevents the system from immediately snapping back to sleep

> If you are prepared to exclude untrusted apps from perfectly reliable
> event reporting (ie from finger to application action) that doesn't seem
> to be a neccessity anyway.

Currently in the Android userpace only trusted (system) apps can
directly obtain wakelocks -- arbitrary apps obtain them via rpc to a
trusted system service (which ensures the app has been granted
permission to do this and tracks usage for accountability to
user/developer).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Igor Stoppa on
ext Alan Cox wrote:

> Be that as it may the question of how you manage a naughty app is a good
> one. Historically we've managed them for network abuse, memory abuse, cpu
> use abuse, access rights, but not yet power.
>
> Whether that looks like
>
> setrlimit(pid, LIMIT_CHARGE, 150mWH);
>
> or
> setrlimit(pid, LIMIT_POWER, 150mW);
>
> or something else is the question.

Either way, this will require a detailed model of the system in terms of
latency, throughput, current consumption and heat generation.

Which can be provided only by the HW manufacturer.

But, should such model be available (and we have some form of it for the
OMAP3 in N900), then it can be abstracted through generic interfaces,
which accept constraints and produce the selected target state
(typically a vector of states for each sub component).

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