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

> 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.

True. If the untrusted apps can be segregated and forcibly stopped,
and if they don't need timely delivery of wakeup events, then there's
no problem.

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: Florian Mickler on
On Fri, 28 May 2010 16:59:54 +0200
Peter Zijlstra <peterz(a)infradead.org> wrote:

> So lets look at the problem, we want to be frugal with power, this means
> that the system as a whole should strive to do nothing. And we want to
> enforce this as strict as possible.

An interesting thought might be to add the costs of staying in
a state versus going to a lower power state into consideration.

If the system is busy doing stuff it would need to do anyway (today
stuff that is guarded/annotated by the suspend blockers) , the costs for
not being in suspend have to be paid anyway. So it is opportune for
processes to run. Even if they by themselves would not justify the
system running.

If instead nothing system-relevant has to be done, the costs of running
anything non-relevant is the full amount of battery-life that could
be saved by suspending + (some minor) running costs.

Also if there is much work to do (many tasks) its more likely that it's
good to do the work.

something along the lines :

(amount of energy saved by being in suspend) / (number of tasks we
would run if we werent suspended) *
some_parameter_for_this_tasks_importance (which falls clearly into
scheduler-territory)

And if this goes above some threshold we run it.

But this isn't easily done in a robust way.
Also it complicates things.

Cheers,
Flo
--
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
> 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).

That's why I suggested "manyana" (can't get accents for ma�ana in a
define) or perhaps "dreckly"[1]. They are both words that mean "at some
point" but in a very very vague and 'relax it'll happen eventually' sense.

More importantly it's policy. It's a please meet this constraint guide
to the PM layer - not a you must do as say even if its stupid.

> > 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.

Cool. I think they are or at least they are close enough that nobody will
notice the join ;)

> > 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.

I'm not sure avoided is the right description - its there in all its
identical ugliness in wakelock magic

If you treat QoS guarantees as a wakelock for your purposes (which is
just fine, drivers and apps give you policy, you use it how you like)
then you could write the paragraph below substituting the word
'guarantee' for 'wakelock' So in that sense the mess is the same because
in both cases you are trying to suspend active tasks rather than asking
the task to behave and then taking remedial action with offenders.

> - 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

The conventional PC model is 'we don't go back into sleep proper fast
enough for that race to occur'. It's hard to see how you change it. An
app->device "thank you for that event, I enjoyed it very much and have
finished with it" message moves the underlying event management and QoS
knowledge into he driver proper but doesn't really change the interface.

> > 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).

Clearly that would continue to work out.

Alan
[1] Dreckly being used in Cornwall, as one friend put it 'Like man�na but
without that dreadful sense of urgency'

--
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 Stern on
On Fri, 28 May 2010, Alan Cox wrote:

> > 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).
>
> That's why I suggested "manyana" (can't get accents for ma�ana in a
> define) or perhaps "dreckly"[1]. They are both words that mean "at some
> point" but in a very very vague and 'relax it'll happen eventually' sense.

A USA-style equivalent phrase might be "Real Soon Now". Except that it
conveys a strong implication that the event will never happen...

> > 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.
>
> Cool. I think they are or at least they are close enough that nobody will
> notice the join ;)

Why are suspend blockers needed if you're going to put all untrusted
apps in a cgroup and freeze/stop them? Or is that not what you're
planning to do?

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: Bernd Petrovitsch on
On Fre, 2010-05-28 at 12:45 +0100, Matthew Garrett wrote:
> On Fri, May 28, 2010 at 12:03:08PM +0200, Bernd Petrovitsch wrote:
> > On Don, 2010-05-27 at 22:28 +0100, Matthew Garrett wrote:
> > > At the point where you're rewriting the application you can just make it
> > > adhere to our current behavioural standards anyway.
> >
> > Thank you for confirming that the so-called "feature" is just there to
> > make apps work in some area that are crappy anyways - and God knows in
> > which other areas they are crappy too.
>
> Kind of like memory protection, really. Or preemptive multitasking. Or
> many things that the kernel does to prevent badly written applications
> from interfering with other applications or the user's experience.

With the main difference that their semantics and API is defined by the
lower layer so that the lower layer can make useful - for the
multitasking part - scheduling decisions.
There were other forms of multitasking before preemptive multitasking -
coroutines (e.g. in Win-3.x quite late in IT history) and the like.
So why not simply skip one step in evolution and go more directly to a
useful solution?

Bernd
--
Bernd Petrovitsch Email : bernd(a)petrovitsch.priv.at
LUGA : http://www.luga.at

--
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/