Re: suspend blockers Android integration

[Peter Zijlstra]

On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
  Trusted processes are assumed to be sane and idle when there is nothing
  for them to do, allowing the machine to go into deep idle states.
 
 
 Neither the kernel nor our trusted user-space code currently meets
 this criteria. 

Then both need fixing. Really, that's the only sane approach.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Thomas Gleixner]

B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:

 2010/6/4 Thomas Gleixner t...@linutronix.de:
  Arve,
 
  On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
 
  On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
   On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
   I kind of agree here, so I'd like to focus a bit on that.
  
   Here's my idea in the very general terms:
  
   (1) Use the cgroup freezer to suspend the untrusted apps (ie. the 
   ones
       that don't use suspend blockers aka wakelocks in the Android world) 
   at the
       point Android would normally start opportunistic suspend.
  
   There is an additional benefit to this approach:
  
       In the current android world a background task (e.g. download
       initiated before the screensaver kicked in) prevents the suspend,
       but that also means that the crapplications can still suck power
       completely unconfined.
  
 
  Yes this can happen. It is usually only a big problem when you combine
  an (trusted) application that has a bug that blocks suspend forever
  with an application that wakes up too often for us to enter low power
  idle modes.
 
  Why is it a BUG in the trusted app, when I initiate a download and put
  the phone down ?
 
 
 It is not, but we have had bugs where a trusted app does not unblock
 suspend after some failure case where it is no longer making any
 progress.

Well, that's simply an application bug which sucks battery with or
without suspend blockers. So it's unrelated to the freezing of
untrusted apps while a trusted app still works in the background
before allowing the machine to suspend.
 
  That download might take a minute or two, but that's not an
  justification for the crapplication to run unconfined and prevent
  lower power states.
 
 
 I agree, but this is not a simple problem to solve.

Not with suspend blockers, but with cgroup confinement of crap, it's
straight forward.

       With the cgroup freezer you can suspend them right away and
       just keep the trusted background task(s) alive which allows us to
       go into deeper idle states instead of letting the crapplications
       run unconfined until the download finished and the suspend
       blocker goes away.
  
 
  Yes this would be better, but I want it in addition to suspend, not
  instead of it. It is also unclear if our user-space code could easily
  make use of it since our trusted code calls into untrusted code.
 
  Sorry, that's really the worst argument I saw in this whole
  discussion.
 
  You're basically saying, that you have no idea what your user space
  stack is doing and you do not care at all as long as your suspend
  blocker scheme makes things work somehow.
 
 
 Yes I don't know everything our user-space stack is doing, but I do
 know that it makes many calls between processes (and in both
 directions). As far as I know it uses timeouts when calling into
 untrusted code, so a misbehaving application will cause an error
 dialog to pop up asking if the user if it should wait longer or
 terminate the application.

Sigh, the more I learn about the details of android and it's violation
of all sane engineering principles the more I understand why you
invented a huge nail to push through all layers in order to bring the
system into idle at all. And yes, you need a sledge hammer to drive
that big nail through everything, so you are using the right tool.

Seriously, the cross app call goes through your framework, which
already knows, that the untrusted part is frozen. So it can deal
nicely with it in any way you want including unfreezing.

  Up to that point, I really tried hard to step back from my initial
  OMG, promoting crap is a nono reaction and work with you on a
  sensible technical solution to confine crap and make it aligned with
  other efforts in this area.
 
  So now, after I spent a reasonable amount of time (as you did) to
  understand what your requirements are, you come up with another
  restriction which is so outside of any level of sanity, that I'm at
  the point of giving up and just going into NAK mode.
 
 
 I don't think this is a new restriction. Both Brian and I have
 mentioned that we have a lot of dependencies between processes.
 
  Can you please answer the following question:
 
     What is the point of having the distinction of trusted and
     untrusted when you have no way to prevent trusted code calling
     into untrusted code ?
 
 
 Trusted code that calls into untrusted code has to deal with the
 untrusted code not responding, but we only want to pop up a message
 that the application is not responding if it is misbehaving, not just
 because it was frozen though no fault of its own.

See above.
 
  That's violating any sense of abstraction and layering and makes it
  entirely clear that the only way you can deal with your own design
  failure is a big hammer which you need to force into the kernel.
 
 
 How can it be fixed? The user presses the back button, the 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Mon, May 31, 2010 at 8:55 AM, Igor Stoppa igor.sto...@nokia.com wrote:
 ext Felipe Contreras wrote:

 I think this information can be obtained dynamically while the
 application is running,

 yes, that was the idea

  and perhaps the limits can be stored. It would
 be pretty difficult for the applications to give this kind of
 information because there are so many variables.

 For example, an media player can tell you: this clip has 24 fps, but
 if the user is moving the time slider, the fps would increase and drop
 very rapidly, and how much depends at least on the container format
 and type of seek.


 I doubt that belongs to typical QoS. Maybe the target could be to be able to
 decode a sequence of i-frames?

I'm not sure what you mean. I-frames comes usually one per second, so
if you only decode I-frames, your experience would be really bad.
Moreover, you don't know beforehand when an I-frame is coming, only
when it's there, and some clips can have only one I-frame at the
beginning.

 A game or a telephony app could tell you I need real-time priority
 but so much as giving the details of latency and bandwidth? I find
 that very unlikely.


 from my gaming days the games were still evaluated in fps ... maybe i made
 the wrong assumption?

Yes, the more fps, the better, but you calculate that by counting the
amount of frames rendered over a period of time; you know the fps
*after* the fact.

 A telephony app should still be able to tell if it's dropping audio frames.

Yes, which could be unrelated to PM, like bad network conditions, but
yeah, it should also be able to tell if the problem is with the
application itself (audio decoder too slow).

 In all cases there should be some device independent limit - like: what is
 the sort of degradation that is considered acceptable by the typical user?

It is easy to tell after the PM actions have been made, as in wait!
I'm not able to perform gimme more power!. But I don't see how that
could be done _before_ the PM actions are done.

From all the QoS proposals I have seen here, and considering that some
people said that suspend blockers could be a specific case of QOS, I
don't think people have been considering QoS as something to state
_after_.

 Tuning might be offered, but at least this should set some sane set of
 defaults.

Huh? Defaults in what units, based on what, and when and how to update?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Mon, May 31, 2010 at 11:47 PM, Florian Mickler flor...@mickler.org wrote:
 On Mon, 31 May 2010 22:12:19 +0200
 Florian Mickler flor...@mickler.org wrote:
 If I have a simple shell script then I don't wanna jump through
 hoops just to please your fragile kernel.

 Also why should that code on one device kill my uptime and on the
 other machine (my wall-plugged desktop) work just well? That doesn't
 sound right.

Sounds perfectly right to me; one code runs perfectly fine on one
machine, and on the other doesn't even compile. Well, sure, it wasn't
written with that use-case in mind.

 Clearly opportunistic suspend is a workaround for battery-driven devices
 and no general solution. But it is not specific to android. At least
 not inherently. It could be useful for any embedded or mobile device
 where you can clearly distinguish important functions from convenience
 functions.

Yes, it could, but why go for the hacky solution when we know how to
achieve the ideal one?

 I really can't understand the whole _fundamental_ opposition to this
 design choice.

Nobody is using it, except Android. Nobody will use it, except Android.

I have seen recent proposals that don't require changing the whole
user-space. That might actually be used by other players.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki r...@sisk.pl wrote:
 Do you realistically think that by hurting the _user_ you will make the
 _developer_ write better code?  No, really.

As an application writer, if my users complain that their battery is
being drained (as it happened), they stop using it, and other people
see there are problems, so they stop using it, if people get angry
about it they will vote it down.

New users will see it has low score; they will not install it. That's
a network effect.

Having users is the quintessential reason people write code.

 If the user likes the app very much (or depends on it or whatever makes him
 use it), he will rather switch the platform to one that allows him to run that
 app without _visible_ problems than complain to the developer, because _the_
 _user_ _doesn't_ _realize_ that the app is broken.  From the user's
 perspective, the platform that has problems with the app is broken, because
 the app apparently runs without problems on concurrent platforms.

Yeah, right. I don't think anybody has every bought an iPhone because
of Tweetie. People care how the applications run on their phones, not
how their phone's platform runs their favorite application, in fact,
most probably it became their favorite application because it was
running great on their phone, and they wouldn't expect it to run on
phones with other platforms. Either applications run on S60, iPhone
OS, Android, or Maemo, but not in a combination of those. And if their
certain app that runs on multiple platforms, and the user actually
knows that (probably a geek), then he knows he can't expect it to work
exactly the same.

 The whole no reason to tolerate broken apps midset is simply misguided IMO,
 because it's based on unrealistic assumptions.  That's because in general 
 users
 only need the platform for running apps they like (or need or whatever).  If
 they can't run apps they like on a given platform, or it is too painful to 
 them
 to run their apps on it, they will rather switch to another platform than stop
 using the apps.

You seriously think people switch high-end phones just to run their
favorite apps? It's much cheaper to switch apps, and that's what users
do.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra pet...@infradead.org wrote:
 On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
 On Thu, 03 Jun 2010 09:40:02 +0200
 Peter Zijlstra pet...@infradead.org wrote:

  Same for firefox, you can teach it to not render animated gifs and run
  javascript for invisible tabs, and once the screen-saver kicks in,
  nothing is visible (and with X telling apps their window is visible or
  not it knows), so it should go idle all of its own.
 
  Fix the friggin apps, don't kludge with freezing.

 Of course programs should be as smart as possible. But that is an
 orthogonal problem.

 Suppose firefox were fixed. It still needs to fetch my rss feeds every
 minute, because I'm sad if it doesn't. It just can't be fixed at the
 application level.

 Sure it can, why would it need to fetch RSS feeds when the screen is off
 and nobody could possible see the result? So you can stop the timer when
 you know the window isn't visible or alternatively when the screensaver
 is active, I think most desktops have notification of that as well.

Exactly, and that's what applications in the N900 do. For this to work
reliably, you need these notifications (network disconnected, screen
off) to be easily accessible, and even transparent to the application
writer.

I don't think the suspend blockers solve much. A bad application will
behave bad on any system. Suppose somebody decides to port Firefox to
Android, and forgets to listen to the screen off event (bad on Android
or Maemo), however, notices the application behaves very badly, so by
googling finds these suspend blockers, and enables them all the time
the application runs.

When the user install the application, will be greeted by a warning
This application might break PM, do you want to enable suspend
blockers? (or whatever), as any typical user would do, will press Yes
(whatever).

We end up in exactly the same situation.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

2010/6/2 Arve Hjønnevåg a...@android.com:
 2010/6/2 Peter Zijlstra pet...@infradead.org:
 (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
 fixing it, get over it already).


 I don't think it is realistic to drop support for all existing hardware.

We are talking about mainline here, there's no support for suspend
blockers, so nothing is dropped.

In the mind of everybody, suspend blockers is for opportunistic
suspend, which only makes sense on sensible hw (not current x86). So
in the mind of everybody, x86 should be out of scope for the analysis
of suspend blockers.

Are you seriously suggesting that one of the strong arguments in favor
of suspend blockers is x86 usage (nobody agrees)? If not, then drop
it.

 Unrelated to
 Android, I also want to use opportunistic suspend on my desktop.

 So you're going to sprinkle this suspend blocker shite all over regular
 userspace?

 I have said several times, that regular user-space will not need to be
 modified to maintain their current behavior.

If I enable suspend blockers on my laptop, I have to modify my
user-space. Otherwise my system will behave horribly.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Rafael J. Wysocki]

On Saturday 05 June 2010, Arve Hjønnevåg wrote:
 2010/6/4 Matt Helsley matth...@us.ibm.com:
  On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
  On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de wrote:
   On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
 
  snip
 
 
   With the cgroup freezer you can suspend them right away and
   just keep the trusted background task(s) alive which allows us to
   go into deeper idle states instead of letting the crapplications
   run unconfined until the download finished and the suspend
   blocker goes away.
  
 
  Yes this would be better, but I want it in addition to suspend, not
  instead of it. It is also unclear if our user-space code could easily
  make use of it since our trusted code calls into untrusted code.
 
 
  Perhaps I'm misunderstanding, but suspend and the cgroup freezer
  interoperate well today -- you don't have to choose one or the other.
  If you've discovered otherwise I'd consider it a bug and would like to
  hear more about it.
 
 
 I'm not aware of any bug with combining both, but we cannot use
 suspend at all without suspend blockers in the kernel (since wakeup
 events may be ignored)

The more I think of it, the more it appears to me that the problem of
lost wakeup events can actually be solved without suspend blockers.
I'll send a bunch of patches to address this issue, probably tomorrow.

 and I don't know how we can safely freeze
 cgroups without funneling all potential wakeup events through a
 process that never gets frozen.

If your untrusted apps get called by the trusted ones, they aren't really
untrusted in the first place.

From what you're saying it follows that you're not really willing to accept
any solution different to your suspend blockers.  Is that really the case?

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] serial: Add OMAP high-speed UART driver

[Luke-Jr]

How do I actually get this to work? Built a kernel with it for my N810, but 
there's no ttyO* (I'm using devtmpfs)...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Saturday 05 June 2010, Felipe Contreras wrote:
 On Mon, May 31, 2010 at 11:47 PM, Florian Mickler flor...@mickler.org wrote:
  On Mon, 31 May 2010 22:12:19 +0200
  Florian Mickler flor...@mickler.org wrote:
  If I have a simple shell script then I don't wanna jump through
  hoops just to please your fragile kernel.
 
  Also why should that code on one device kill my uptime and on the
  other machine (my wall-plugged desktop) work just well? That doesn't
  sound right.
 
 Sounds perfectly right to me; one code runs perfectly fine on one
 machine, and on the other doesn't even compile. Well, sure, it wasn't
 written with that use-case in mind.
 
  Clearly opportunistic suspend is a workaround for battery-driven devices
  and no general solution. But it is not specific to android. At least
  not inherently. It could be useful for any embedded or mobile device
  where you can clearly distinguish important functions from convenience
  functions.
 
 Yes, it could, but why go for the hacky solution when we know how to
 achieve the ideal one?
 
  I really can't understand the whole _fundamental_ opposition to this
  design choice.
 
 Nobody is using it, except Android. Nobody will use it, except Android.

That's like saying Android is not a legitimate user of the kernel.  Is that
you wanted to say?

 I have seen recent proposals that don't require changing the whole
 user-space. That might actually be used by other players.

Sure, an approach benefitting more platforms than just Android would be better,
but saying that the kernel shouldn't address the Android's specific needs as a
rule if no one else has those needs too is quite too far reaching to me.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
 
  I have seen recent proposals that don't require changing the whole
  user-space. That might actually be used by other players.
 
 Sure, an approach benefitting more platforms than just Android would be 
 better,
 but saying that the kernel shouldn't address the Android's specific needs as a
 rule if no one else has those needs too is quite too far reaching to me. 

Well, if the android people keep rejecting all sensible approaches to
power savings except their suspend blocker mess, then I don't see why we
should support their ill designed mess.

We should strive to provide an interface that can be used by all
interested parties to conserve power; if Android really is the only
possible user of the interface then I don't see any reason at all to
merge it, they might as well keep it in their private tree.



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Rafael J. Wysocki]

On Saturday 05 June 2010, Peter Zijlstra wrote:
 On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote:
  
   I have seen recent proposals that don't require changing the whole
   user-space. That might actually be used by other players.
  
  Sure, an approach benefitting more platforms than just Android would be 
  better,
  but saying that the kernel shouldn't address the Android's specific needs 
  as a
  rule if no one else has those needs too is quite too far reaching to me. 
 
 Well, if the android people keep rejecting all sensible approaches to
 power savings except their suspend blocker mess, then I don't see why we
 should support their ill designed mess.

Well, I certainly would like the Android people to be more appreciative of our
ideas if they expect reciprocity.

 We should strive to provide an interface that can be used by all
 interested parties to conserve power; if Android really is the only
 possible user of the interface then I don't see any reason at all to
 merge it, they might as well keep it in their private tree.

There is a number of kernel users that depend on Android user space
(phone vendors using Android on their hardware, but providing their own
drivers), so I don't think we really can identify Android with Google in that
respect.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 20:16:33 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki r...@sisk.pl wrote:
  Do you realistically think that by hurting the _user_ you will make the
  _developer_ write better code?  No, really.
 
 As an application writer, if my users complain that their battery is
 being drained (as it happened), they stop using it, and other people
 see there are problems, so they stop using it, if people get angry
 about it they will vote it down.
 
 New users will see it has low score; they will not install it. That's
 a network effect.
 
 Having users is the quintessential reason people write code.
 

That is nice. But how does it impact the problem that suspend blockers
solve? And why do suspend blockers interfere with that?

Cheers,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Peter Zijlstra]

On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote:
 
 There is a number of kernel users that depend on Android user space
 (phone vendors using Android on their hardware, but providing their own
 drivers), so I don't think we really can identify Android with Google in that
 respect.

I don't see why we can't merge the platform code and drivers without
suspend blockers. Google can patch them back in on their side if they
want to.



--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki r...@sisk.pl wrote:
 On Saturday 05 June 2010, Felipe Contreras wrote:
 On Mon, May 31, 2010 at 11:47 PM, Florian Mickler flor...@mickler.org 
 wrote:
  On Mon, 31 May 2010 22:12:19 +0200
  Florian Mickler flor...@mickler.org wrote:
  If I have a simple shell script then I don't wanna jump through
  hoops just to please your fragile kernel.
 
  Also why should that code on one device kill my uptime and on the
  other machine (my wall-plugged desktop) work just well? That doesn't
  sound right.

 Sounds perfectly right to me; one code runs perfectly fine on one
 machine, and on the other doesn't even compile. Well, sure, it wasn't
 written with that use-case in mind.

  Clearly opportunistic suspend is a workaround for battery-driven devices
  and no general solution. But it is not specific to android. At least
  not inherently. It could be useful for any embedded or mobile device
  where you can clearly distinguish important functions from convenience
  functions.

 Yes, it could, but why go for the hacky solution when we know how to
 achieve the ideal one?

  I really can't understand the whole _fundamental_ opposition to this
  design choice.

 Nobody is using it, except Android. Nobody will use it, except Android.

 That's like saying Android is not a legitimate user of the kernel.  Is that
 you wanted to say?

Read the context: opportunistic suspend, which is considered a
workaround, which requires new user-space API for suspend blockers,
might be remotely considered for inclusion *if* it indeed solves a
problem for battery-driven devices, which other parties also
experience and could benefit from this solution.

The answer: no, it doesn't: only Android user-space will benefit from it.

 I have seen recent proposals that don't require changing the whole
 user-space. That might actually be used by other players.

 Sure, an approach benefitting more platforms than just Android would be 
 better,
 but saying that the kernel shouldn't address the Android's specific needs as a
 rule if no one else has those needs too is quite too far reaching to me.

There are no Android specific needs, why should certain user-space
ecosystem need certain API that somehow *nobody* else does? I think in
this huge thread it has become obvious that people are reluctant to
this idea... whatever problem Android user-space presents (I don't
think there's any), it can be solved for he rest of the world too,
and such generic solution is worth exploring.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 20:30:40 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra pet...@infradead.org wrote:
  On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote:
  On Thu, 03 Jun 2010 09:40:02 +0200
  Peter Zijlstra pet...@infradead.org wrote:
 
   Fix the friggin apps, don't kludge with freezing.
 
  Of course programs should be as smart as possible. But that is an
  orthogonal problem.
 
  Suppose firefox were fixed. It still needs to fetch my rss feeds every
  minute, because I'm sad if it doesn't. It just can't be fixed at the
  application level.
 
  Sure it can, why would it need to fetch RSS feeds when the screen is off
  and nobody could possible see the result? So you can stop the timer when
  you know the window isn't visible or alternatively when the screensaver
  is active, I think most desktops have notification of that as well.
 
 Exactly, and that's what applications in the N900 do. For this to work
 reliably, you need these notifications (network disconnected, screen
 off) to be easily accessible, and even transparent to the application
 writer.
 
 I don't think the suspend blockers solve much. A bad application will
 behave bad on any system. Suppose somebody decides to port Firefox to
 Android, and forgets to listen to the screen off event (bad on Android
 or Maemo), however, notices the application behaves very badly, so by
 googling finds these suspend blockers, and enables them all the time
 the application runs.
 
 When the user install the application, will be greeted by a warning
 This application might break PM, do you want to enable suspend
 blockers? (or whatever), as any typical user would do, will press Yes
 (whatever).
 
 We end up in exactly the same situation.
 
No. The application will show up in the suspend blocker stats and the
user will remember: Oh, yes. There was a warning about that. Well I
think I'm going to file a bug there.

The only difference is, that with suspend blockers, he can than
dismiss the applications permission to block suspend and will not miss
his job interview the next day because his phones battery run
out. And also he can use the application to a certain extent.

Cheers,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler flor...@mickler.org wrote:
 On Sat, 5 Jun 2010 20:16:33 +0300
 Felipe Contreras felipe.contre...@gmail.com wrote:
 New users will see it has low score; they will not install it. That's
 a network effect.

 Having users is the quintessential reason people write code.

 That is nice. But how does it impact the problem that suspend blockers
 solve? And why do suspend blockers interfere with that?

It doesn't, I don't know why people keep bringing this argument, I
just though it should not be left open as a valid one.

I should have mentioned that this is indeed irrelevant.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 20:44:24 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 2010/6/2 Arve Hjønnevåg a...@android.com:
  2010/6/2 Peter Zijlstra pet...@infradead.org:
  (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
  fixing it, get over it already).
 
 
  I don't think it is realistic to drop support for all existing hardware.
 
 We are talking about mainline here, there's no support for suspend
 blockers, so nothing is dropped.
 
 In the mind of everybody, suspend blockers is for opportunistic
 suspend, which only makes sense on sensible hw (not current x86). So
 in the mind of everybody, x86 should be out of scope for the analysis
 of suspend blockers.
 
 Are you seriously suggesting that one of the strong arguments in favor
 of suspend blockers is x86 usage (nobody agrees)? If not, then drop
 it.

I think they have an advantage over the
30-minute-screensaver-then-suspend that current desktops do. Because
you can define what keeps the system up. I.e. the
screensaver/powermanager is not limited to keyboard- and
mouse-inactivity.

 If I enable suspend blockers on my laptop, I have to modify my
 user-space. Otherwise my system will behave horribly.
 

In the simplest case you have a shell script which takes a suspend
blocker and reads from stdinput. When you write mem to it, it
releases the suspend blocker and acquires it back again. Voila, forced
suspend reimplemented on top of opportunistic suspend.

That wasn't hard, was it? 

Cheers,
Flo
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Felipe Contreras]

On Sat, Jun 5, 2010 at 11:01 PM, Florian Mickler flor...@mickler.org wrote:
 On Sat, 5 Jun 2010 20:44:24 +0300
 Felipe Contreras felipe.contre...@gmail.com wrote:

 2010/6/2 Arve Hjønnevåg a...@android.com:
  2010/6/2 Peter Zijlstra pet...@infradead.org:
  (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're
  fixing it, get over it already).
 
 
  I don't think it is realistic to drop support for all existing hardware.

 We are talking about mainline here, there's no support for suspend
 blockers, so nothing is dropped.

 In the mind of everybody, suspend blockers is for opportunistic
 suspend, which only makes sense on sensible hw (not current x86). So
 in the mind of everybody, x86 should be out of scope for the analysis
 of suspend blockers.

 Are you seriously suggesting that one of the strong arguments in favor
 of suspend blockers is x86 usage (nobody agrees)? If not, then drop
 it.

 I think they have an advantage over the
 30-minute-screensaver-then-suspend that current desktops do. Because
 you can define what keeps the system up. I.e. the
 screensaver/powermanager is not limited to keyboard- and
 mouse-inactivity.

What prevents you from defining other things keeping the system up
right now? Nothing. It's up to user-space to decide when to suspend.
In fact applications already block suspend; Transmission has the
option to block suspend when downloading torrents.

 If I enable suspend blockers on my laptop, I have to modify my
 user-space. Otherwise my system will behave horribly.


 In the simplest case you have a shell script which takes a suspend
 blocker and reads from stdinput. When you write mem to it, it
 releases the suspend blocker and acquires it back again. Voila, forced
 suspend reimplemented on top of opportunistic suspend.

 That wasn't hard, was it?

Not hard, but still a modification of user-space, and a pretty bad one
because it will prevent typical forced suspend, and typical suspend
delaying (like with Transmission). Supposing the opportunistic suspend
doesn't block the forced suspend, still, absolutely nothing will be
achieved by enabling suspend blockers.

If you want to take even a minimal advantage of suspend blockers you
need serious modifications to user-space.

Supposing there's a perfect usage of suspend blockers from user-space
on current x86 platforms (in theory Android would have that), is the
benefit that big to consider this a strong argument in favor of
suspend blockers? Considering the small amount of x86 platforms using
Android (is there any?), the fact that nobody else will use suspend
blockers, and that x86 is already being fixed (as mentioned many times
before) so dynamic PM is possible, I don't think we should be
considering current x86 at all for suspend blockers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Florian Mickler]

On Thu, 3 Jun 2010 19:16:55 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:

 The thing is, unless there is some _really_ deep other reason to do 
 something like this, I still think it's total overdesign to push any 
 knowledge/choices like this into the scheduler. I'd rather keep things way 
 more independent, less tied to each other and to deep kernel subsystems.
 
 IOW, my personal opinion is that somethng like a suspend (blocker or not) 
 decision simply shouldn't be important enough to be tied into the 
 scheduler. Especially not if it could just be its own layer.
 
 That said, as far as I know, the Android people have mostly been looking 
 at the suspend angle from a single-core standpoint. And I'm not at all 
 convinced that they should hijack the existing /sys/power/state thing 
 which is what I think they do now.
 
 And those two things go together. The /sys/power/state thing is a global 
 suspend - which I don't think is appropriate for a opportunistic thing in 
 the first place, especially for multi-core.
 

This sounds right. 

If there is soo much need for a better solution, it will emerge. With
merged suspend blockers or not.

Just my 2 cents.

   Linus

Cheers,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 23:06:03 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 On Sat, Jun 5, 2010 at 10:56 PM, Florian Mickler flor...@mickler.org wrote:
  On Sat, 5 Jun 2010 20:30:40 +0300
  Felipe Contreras felipe.contre...@gmail.com wrote:
  I don't think the suspend blockers solve much. A bad application will
  behave bad on any system. Suppose somebody decides to port Firefox to
  Android, and forgets to listen to the screen off event (bad on Android
  or Maemo), however, notices the application behaves very badly, so by
  googling finds these suspend blockers, and enables them all the time
  the application runs.
 
  When the user install the application, will be greeted by a warning
  This application might break PM, do you want to enable suspend
  blockers? (or whatever), as any typical user would do, will press Yes
  (whatever).
 
  We end up in exactly the same situation.
 
  No. The application will show up in the suspend blocker stats and the
  user will remember: Oh, yes. There was a warning about that. Well I
  think I'm going to file a bug there.
 
 How would such stats be calculated? I presume at regular intervals you
 check which applications are holding suspend blockers and increase a
 counter.
 
 How would you do that with the dynamic PM approach? At regular
 intervals you check for which applications are running (not idle).

IIRC, the patches discussed have debugging infrastructure in
them. The kernel does the accounting. 

 
  The only difference is, that with suspend blockers, he can than
  dismiss the applications permission to block suspend and will not miss
  his job interview the next day because his phones battery run
  out. And also he can use the application to a certain extent.
 
 So the difference is between removing the app, and making it run
 crappy. I don't think that's a strong argument in favor of suspend
 blockers.
 
If you think a little about it, it is. Because if the app wouldn't be
usable at all, the bug wouldn't get fixed because the user wouldn't use
it. Or not?

Cheers,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 23:26:27 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 Supposing there's a perfect usage of suspend blockers from user-space
 on current x86 platforms (in theory Android would have that), is the
 benefit that big to consider this a strong argument in favor of
 suspend blockers? Considering the small amount of x86 platforms using
 Android (is there any?), the fact that nobody else will use suspend
 blockers, and that x86 is already being fixed (as mentioned many times
 before) so dynamic PM is possible, I don't think we should be
 considering current x86 at all for suspend blockers.

A solution for the desktop to deprecate having to shut down the
machine would not be that bad, wouldn;t it? (Why have I to shut down
my machine anyway?) 

In my opinion such a decision (when to shutdown) has to be guided by
userspace knowledge.
Future x86 hardware is to be fixed (as I read in this discussion), so
using suspend blockers could be the tool of choice. 

But alright. Let's be a little bit more focused on the present
situation:

1) There currently is no other solution.
2) It is a first stepping stone to bringing android to mainline.
3) Any perfect solution will emerge anyway. As there are so many
people with so strong opinions engaged in this discussion, I'm
confident.
4) If there is a better solution, android will shurely adapt it as
soon as it is there. 

Cheers,
Flo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Sat, 5 Jun 2010, Florian Mickler wrote:
 On Sat, 5 Jun 2010 23:26:27 +0300
 Felipe Contreras felipe.contre...@gmail.com wrote:
 
  Supposing there's a perfect usage of suspend blockers from user-space
  on current x86 platforms (in theory Android would have that), is the
  benefit that big to consider this a strong argument in favor of
  suspend blockers? Considering the small amount of x86 platforms using
  Android (is there any?), the fact that nobody else will use suspend
  blockers, and that x86 is already being fixed (as mentioned many times
  before) so dynamic PM is possible, I don't think we should be
  considering current x86 at all for suspend blockers.
 
 A solution for the desktop to deprecate having to shut down the
 machine would not be that bad, wouldn;t it? (Why have I to shut down
 my machine anyway?) 
 
 In my opinion such a decision (when to shutdown) has to be guided by
 userspace knowledge.
 Future x86 hardware is to be fixed (as I read in this discussion), so
 using suspend blockers could be the tool of choice. 
 
 But alright. Let's be a little bit more focused on the present
 situation:
 
 1) There currently is no other solution.

Wrong. The solutions are there, just being refused.

 2) It is a first stepping stone to bringing android to mainline.

Crap. Once we have an userspace API we are bound to it. Period. 

Also there is no technical reason why the whole driver stack cannot
be merged w/o the suspend blockers.

 3) Any perfect solution will emerge anyway. As there are so many
 people with so strong opinions engaged in this discussion, I'm
 confident.

Yes, and that needs cooperation and compromises from both sides and
not just blindly defining that there is no other solution.

 4) If there is a better solution, android will shurely adapt it as
 soon as it is there. 

Sure, after we accepted the crap there is no incentive at all.

Stop that advertising campaing already.

No thanks,

tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven ar...@infradead.org wrote:
 On Sat, 05 Jun 2010 11:54:13 +0200
 Peter Zijlstra pet...@infradead.org wrote:

 On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
   Trusted processes are assumed to be sane and idle when there is
   nothing for them to do, allowing the machine to go into deep idle
   states.
  
 
  Neither the kernel nor our trusted user-space code currently meets
  this criteria.

 Then both need fixing. Really, that's the only sane approach.

 fwiw... in MeeGo we're seeing quite good idle times ( 1 seconds)
 without really bad hacks.


We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a noticeable decrease in battery life on
the hardware we have today.

 the kernel has a set of infrastructure already to help here (range
 timers, with which you can wakeup-limit untrusted userspace crap),
 timer slack for legacy background timers, etc etc.

Range timers allows the kernel to align different timers so they don't
each bring the cpu out of idle individually. They do not eliminate
timers or make individual timers fire less often. For example if you
have 10 timers that fire every second on an idle system, without range
timers you will most likely have to bring the cpu out of idle 10 times
a second, but with range timers you have a chance of waking up only
once a second (I say a chance here, since if they are identical they
will just chase each other and never catch up).


 getting to 10 seconds is not in the range of impossibilities to be
 honest... and that's even without doing things like putting untrusted

That is still far short of what we get with suspend (in terms of time).

 junk (read: Appstore apps) into a cgroup and do wakeup limiting and cpu
 time limiting on a cgroup level


 --
 Arjan van de Ven        Intel Open Source Technology Centre
 For development, discussion and tips for power savings,
 visit http://www.lesswatts.org




-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:

 Stop that advertising campaing already.

Stop advertising that there is no problem. 

 
 No thanks,
 
   tglx

Cheers,
Flo

(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering and not dismissing the problem. This was pointed at
Felipes There is no problem/suspend blockers don't do what they are designed 
to do well)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Thomas Gleixner]

On Sat, 5 Jun 2010, Florian Mickler wrote:

 On Sat, 5 Jun 2010 23:24:40 +0200 (CEST)
 Thomas Gleixner t...@linutronix.de wrote:
 
  Stop that advertising campaing already.
 
 Stop advertising that there is no problem. 
 
  
  No thanks,
  
  tglx
 
 Cheers,
 Flo
 
 (Sorry, crossfire. Caused
 by you answering in the wrong subthread. I know that you are
 engineering and not dismissing the problem. This was pointed at
 Felipes There is no problem/suspend blockers don't do what they are 
 designed to do well)

Welcome to my killfile.

 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Thomas Gleixner t...@linutronix.de:
 B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:

 2010/6/4 Thomas Gleixner t...@linutronix.de:
  Arve,
 
  On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
 
  On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
  wrote:
   On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
   I kind of agree here, so I'd like to focus a bit on that.
  
   Here's my idea in the very general terms:
  
   (1) Use the cgroup freezer to suspend the untrusted apps (ie. the 
   ones
       that don't use suspend blockers aka wakelocks in the Android 
   world) at the
       point Android would normally start opportunistic suspend.
  
   There is an additional benefit to this approach:
  
       In the current android world a background task (e.g. download
       initiated before the screensaver kicked in) prevents the suspend,
       but that also means that the crapplications can still suck power
       completely unconfined.
  
 
  Yes this can happen. It is usually only a big problem when you combine
  an (trusted) application that has a bug that blocks suspend forever
  with an application that wakes up too often for us to enter low power
  idle modes.
 
  Why is it a BUG in the trusted app, when I initiate a download and put
  the phone down ?
 

 It is not, but we have had bugs where a trusted app does not unblock
 suspend after some failure case where it is no longer making any
 progress.

 Well, that's simply an application bug which sucks battery with or
 without suspend blockers. So it's unrelated to the freezing of
 untrusted apps while a trusted app still works in the background
 before allowing the machine to suspend.


It is not unrelated if the trusted app has stopped working but still
blocks suspend. The battery drains when you combine them.

  That download might take a minute or two, but that's not an
  justification for the crapplication to run unconfined and prevent
  lower power states.
 

 I agree, but this is not a simple problem to solve.

 Not with suspend blockers, but with cgroup confinement of crap, it's
 straight forward.


I don't think is is straight forward. If the a process in the frozen
group holds a resource that a process in the unfrozen group needs, how
do deal with that?

       With the cgroup freezer you can suspend them right away and
       just keep the trusted background task(s) alive which allows us to
       go into deeper idle states instead of letting the crapplications
       run unconfined until the download finished and the suspend
       blocker goes away.
  
 
  Yes this would be better, but I want it in addition to suspend, not
  instead of it. It is also unclear if our user-space code could easily
  make use of it since our trusted code calls into untrusted code.
 
  Sorry, that's really the worst argument I saw in this whole
  discussion.
 
  You're basically saying, that you have no idea what your user space
  stack is doing and you do not care at all as long as your suspend
  blocker scheme makes things work somehow.
 

 Yes I don't know everything our user-space stack is doing, but I do
 know that it makes many calls between processes (and in both
 directions). As far as I know it uses timeouts when calling into
 untrusted code, so a misbehaving application will cause an error
 dialog to pop up asking if the user if it should wait longer or
 terminate the application.

 Sigh, the more I learn about the details of android and it's violation
 of all sane engineering principles the more I understand why you
 invented a huge nail to push through all layers in order to bring the
 system into idle at all. And yes, you need a sledge hammer to drive
 that big nail through everything, so you are using the right tool.

 Seriously, the cross app call goes through your framework, which
 already knows, that the untrusted part is frozen. So it can deal
 nicely with it in any way you want including unfreezing.

Cross app calls do not go through a central process.


  Up to that point, I really tried hard to step back from my initial
  OMG, promoting crap is a nono reaction and work with you on a
  sensible technical solution to confine crap and make it aligned with
  other efforts in this area.
 
  So now, after I spent a reasonable amount of time (as you did) to
  understand what your requirements are, you come up with another
  restriction which is so outside of any level of sanity, that I'm at
  the point of giving up and just going into NAK mode.
 

 I don't think this is a new restriction. Both Brian and I have
 mentioned that we have a lot of dependencies between processes.

  Can you please answer the following question:
 
     What is the point of having the distinction of trusted and
     untrusted when you have no way to prevent trusted code calling
     into untrusted code ?
 

 Trusted code that calls into untrusted code has to deal with the
 untrusted code not responding, but we only want to pop up a message
 that the 

Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Florian Mickler]

On Sat, 5 Jun 2010 22:56:45 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:

 On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler flor...@mickler.org wrote:
  On Sat, 5 Jun 2010 20:16:33 +0300
  Felipe Contreras felipe.contre...@gmail.com wrote:
  New users will see it has low score; they will not install it. That's
  a network effect.
 
  Having users is the quintessential reason people write code.
 
  That is nice. But how does it impact the problem that suspend blockers
  solve? And why do suspend blockers interfere with that?
 
 It doesn't, I don't know why people keep bringing this argument, I
 just though it should not be left open as a valid one.
 
 I should have mentioned that this is indeed irrelevant.
 

Uh! I found out how this is relevant to the suspend blockers case.
Because not having users means that the bugs don't get fixed.
Whereas in the suspend blockers case the users can use the app and get
the bugs fixed. 

Cheers,
Flo

p.s.: I really wished you would focus more on solving the
problem and not on dismissing it.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Rafael J. Wysocki r...@sisk.pl:
 On Saturday 05 June 2010, Arve Hjønnevåg wrote:
 2010/6/4 Matt Helsley matth...@us.ibm.com:
  On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
  On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
  wrote:
   On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
 
  snip
 
 
       With the cgroup freezer you can suspend them right away and
       just keep the trusted background task(s) alive which allows us to
       go into deeper idle states instead of letting the crapplications
       run unconfined until the download finished and the suspend
       blocker goes away.
  
 
  Yes this would be better, but I want it in addition to suspend, not
  instead of it. It is also unclear if our user-space code could easily
  make use of it since our trusted code calls into untrusted code.
 
 
  Perhaps I'm misunderstanding, but suspend and the cgroup freezer
  interoperate well today -- you don't have to choose one or the other.
  If you've discovered otherwise I'd consider it a bug and would like to
  hear more about it.
 

 I'm not aware of any bug with combining both, but we cannot use
 suspend at all without suspend blockers in the kernel (since wakeup
 events may be ignored)

 The more I think of it, the more it appears to me that the problem of
 lost wakeup events can actually be solved without suspend blockers.
 I'll send a bunch of patches to address this issue, probably tomorrow.


I know of two ways to prevent lost wakeup events. Reset a timeout
every time you receive a wakeup event or prevents suspend until you
know the event has been fully processed. Does your solution fall onto
one of these two categories, or do you have a third way?

 and I don't know how we can safely freeze
 cgroups without funneling all potential wakeup events through a
 process that never gets frozen.

 If your untrusted apps get called by the trusted ones, they aren't really
 untrusted in the first place.

That is not a correct statement. A trusted apps can call into an
untrusted app, it just has to validate the response and handle not
getting a response at all. There are also different levels of trust. I
may have trusted an app to provide a contact pictures, but not trusted
it to block suspend. When the phone rings the app will be called to
provide the picture for the incoming call dialog, but if it is frozen
at this point the more trusted app that handles the incoming phone
call will not be able to get the picture.

 From what you're saying it follows that you're not really willing to accept
 any solution different to your suspend blockers.  Is that really the case?

I don't think that is a fair way to put it. We need to support our
user-space framework and I have not seen an alternative solution that
clearly will work (other than replacing suspend_blockers with pm_qos
constraints that do the same thing).

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Thomas Gleixner]

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
   Why is it a BUG in the trusted app, when I initiate a download and put
   the phone down ?
  
 
  It is not, but we have had bugs where a trusted app does not unblock
  suspend after some failure case where it is no longer making any
  progress.
 
  Well, that's simply an application bug which sucks battery with or
  without suspend blockers. So it's unrelated to the freezing of
  untrusted apps while a trusted app still works in the background
  before allowing the machine to suspend.
 
 
 It is not unrelated if the trusted app has stopped working but still
 blocks suspend. The battery drains when you combine them.

What you are describing is a problem which is not solvable either way.
If you take the lock and do not release it you're not going to
suspend. I never claimed that any other mechanism resolves this.

But this is not related to the fact that freezing crap while running a
sane background task is going to save you power vs. an approach where
running a sane background task allows crap to consume power unconfined
until it is done.

   That download might take a minute or two, but that's not an
   justification for the crapplication to run unconfined and prevent
   lower power states.
  
 
  I agree, but this is not a simple problem to solve.
 
  Not with suspend blockers, but with cgroup confinement of crap, it's
  straight forward.
 
 
 I don't think is is straight forward. If the a process in the frozen
 group holds a resource that a process in the unfrozen group needs, how
 do deal with that?

I'm going to fix the framework which puts the group into freeze state
w/o making sure that there is no held shared resource. Come on it's
not rocket science.
 
  Yes I don't know everything our user-space stack is doing, but I do
  know that it makes many calls between processes (and in both
  directions). As far as I know it uses timeouts when calling into
  untrusted code, so a misbehaving application will cause an error
  dialog to pop up asking if the user if it should wait longer or
  terminate the application.
 
  Sigh, the more I learn about the details of android and it's violation
  of all sane engineering principles the more I understand why you
  invented a huge nail to push through all layers in order to bring the
  system into idle at all. And yes, you need a sledge hammer to drive
  that big nail through everything, so you are using the right tool.
 
  Seriously, the cross app call goes through your framework, which
  already knows, that the untrusted part is frozen. So it can deal
  nicely with it in any way you want including unfreezing.
 
 Cross app calls do not go through a central process.

It's not about a central process, it goes through your framework,
which should be able to deal with it. If not, it's a design failure
which needs to be fixed at the place where the failure happened.
 
 
  How can it be fixed? The user presses the back button, the framework
  determines that app A is in the foreground and send the key to app A,
  app A decides that it it does not have anything internal to go back to
  and tells the framework to switch back to the previous app. If the
  user presses the back key again, the framework does not know which app
  this key should go to until app A has finished processing the first
  key press.
 
  Errm, what has this to do with frozen apps? If your system is
  handling input events then there are no frozen apps and even if they
  are frozen your framework can unfreeze them _before_ talking to them.
 
  So which unfixable problem are you describing with the above example ?
 
 
 You are claiming that trusted code should not have any dependencies on
 untrusted code. I gave you a visible example of such a dependency and
 want you to tell me how you can avoid this dependency. Since you are
 claiming that our user-space framework is fundamentally broken if it
 has to wait for untrusted code, I don't think it is unreasonable for
 you to answer this. Or do you think it is valid to communicate with
 untrusted code when the screen is on but not when it is off.

It does not matter whether the screen is off or not. If you need to
call into that untrusted app from your trusted app and you know about
the might be frozen state then you can deal with it.

So taking your example:

Event happens and gets delivered to the framework

  framework selects A because it is in the foreground
  
  if (A is frozen)
 unfreeze(A)

  deliver_event_to(A)

It's that simple.

If your framework cannot deal with that simple problem then you have a
much more serious problem already.

Thanks,

tglx

Re: suspend blockers Android integration

[Arjan van de Ven]

On Sat, 5 Jun 2010 14:26:14 -0700
Arve Hjønnevåg a...@android.com wrote:

 On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven
 ar...@infradead.org wrote:
  On Sat, 05 Jun 2010 11:54:13 +0200
  Peter Zijlstra pet...@infradead.org wrote:
 
  On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
Trusted processes are assumed to be sane and idle when there is
nothing for them to do, allowing the machine to go into deep
idle states.
   
  
   Neither the kernel nor our trusted user-space code currently
   meets this criteria.
 
  Then both need fixing. Really, that's the only sane approach.
 
  fwiw... in MeeGo we're seeing quite good idle times ( 1 seconds)
  without really bad hacks.
 
 
 We clearly have different standards for what we consider good. We
 measure time suspended in minutes or hours, not seconds, and waking up
 every second or two causes a noticeable decrease in battery life on
 the hardware we have today.

I guess I'm spoiled working with (unreleased) hardware that knows how
to power gate ;-)


 
  the kernel has a set of infrastructure already to help here (range
  timers, with which you can wakeup-limit untrusted userspace crap),
  timer slack for legacy background timers, etc etc.
 
 Range timers allows the kernel to align different timers so they don't
 each bring the cpu out of idle individually. They do not eliminate
 timers or make individual timers fire less often.

you're incorrect.
With range timers you can control the rate at which timers fire just
fine. 

For example if the Adobe Flash player puts a timer every 10
milliseconds (yes it does that), and you give it a 3.99 seconds range,
it will fire its timers every 4 seconds unless other activity
happens independently, at which point it'll align with that instead.



-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Brian Swetland]

On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:

 We clearly have different standards for what we consider good. We
 measure time suspended in minutes or hours, not seconds, and waking up
 every second or two causes a noticeable decrease in battery life on
 the hardware we have today.

 I guess I'm spoiled working with (unreleased) hardware that knows how
 to power gate ;-)

I'm continually surprised by answers like this.  We run on hardware
that power gates very aggressively and draws in the neighborhood of
1-2mA at the battery when in the lowest state (3-5mA while the radio
is connected to the network and paging).  Waking up out of that lowest
state and executing code every few seconds or (worse) several times a
second) will raise your average power consumption.  Being able to stay
parked at the very bottom for minutes or hours at a time when nothing
interesting is happening is very useful and can have a significant
impact on overall battery life.

Brian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Arjan van de Ven ar...@infradead.org:
 On Sat, 5 Jun 2010 14:26:14 -0700
 Arve Hjønnevåg a...@android.com wrote:

 On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven
 ar...@infradead.org wrote:
  On Sat, 05 Jun 2010 11:54:13 +0200
  Peter Zijlstra pet...@infradead.org wrote:
 
  On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote:
Trusted processes are assumed to be sane and idle when there is
nothing for them to do, allowing the machine to go into deep
idle states.
   
  
   Neither the kernel nor our trusted user-space code currently
   meets this criteria.
 
  Then both need fixing. Really, that's the only sane approach.
 
  fwiw... in MeeGo we're seeing quite good idle times ( 1 seconds)
  without really bad hacks.
 

 We clearly have different standards for what we consider good. We
 measure time suspended in minutes or hours, not seconds, and waking up
 every second or two causes a noticeable decrease in battery life on
 the hardware we have today.

 I guess I'm spoiled working with (unreleased) hardware that knows how
 to power gate ;-)



  the kernel has a set of infrastructure already to help here (range
  timers, with which you can wakeup-limit untrusted userspace crap),
  timer slack for legacy background timers, etc etc.

 Range timers allows the kernel to align different timers so they don't
 each bring the cpu out of idle individually. They do not eliminate
 timers or make individual timers fire less often.

 you're incorrect.
 With range timers you can control the rate at which timers fire just
 fine.

 For example if the Adobe Flash player puts a timer every 10
 milliseconds (yes it does that), and you give it a 3.99 seconds range,
 it will fire its timers every 4 seconds unless other activity
 happens independently, at which point it'll align with that instead.


If you do that what you are delivering is nowhere close to what the
app asked for. You don't need range timers for this, you could just as
well add 4 seconds to all normal timers.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Rafael J. Wysocki]

On Saturday 05 June 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
 
  2010/6/4 Thomas Gleixner t...@linutronix.de:
   Arve,
  
   On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
  
   On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
   wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
   
Here's my idea in the very general terms:
   
(1) Use the cgroup freezer to suspend the untrusted apps (ie. 
the ones
that don't use suspend blockers aka wakelocks in the Android 
world) at the
point Android would normally start opportunistic suspend.
   
There is an additional benefit to this approach:
   
In the current android world a background task (e.g. download
initiated before the screensaver kicked in) prevents the suspend,
but that also means that the crapplications can still suck power
completely unconfined.
   
  
   Yes this can happen. It is usually only a big problem when you combine
   an (trusted) application that has a bug that blocks suspend forever
   with an application that wakes up too often for us to enter low power
   idle modes.
  
   Why is it a BUG in the trusted app, when I initiate a download and put
   the phone down ?
  
 
  It is not, but we have had bugs where a trusted app does not unblock
  suspend after some failure case where it is no longer making any
  progress.
 
  Well, that's simply an application bug which sucks battery with or
  without suspend blockers. So it's unrelated to the freezing of
  untrusted apps while a trusted app still works in the background
  before allowing the machine to suspend.
 
 
 It is not unrelated if the trusted app has stopped working but still
 blocks suspend. The battery drains when you combine them.
 
   That download might take a minute or two, but that's not an
   justification for the crapplication to run unconfined and prevent
   lower power states.
  
 
  I agree, but this is not a simple problem to solve.
 
  Not with suspend blockers, but with cgroup confinement of crap, it's
  straight forward.
 
 
 I don't think is is straight forward. If the a process in the frozen
 group holds a resource that a process in the unfrozen group needs, how
 do deal with that?

That depends a good deal on what you mean by holding a resource.

Generally, however, if your trusted processes depend on the processes you
don't trust, then either the former should not be trusted, or the latter should
be trusted.

With the cgroup freezer you can suspend them right away and
just keep the trusted background task(s) alive which allows us to
go into deeper idle states instead of letting the crapplications
run unconfined until the download finished and the suspend
blocker goes away.
   
  
   Yes this would be better, but I want it in addition to suspend, not
   instead of it. It is also unclear if our user-space code could easily
   make use of it since our trusted code calls into untrusted code.
  
   Sorry, that's really the worst argument I saw in this whole
   discussion.
  
   You're basically saying, that you have no idea what your user space
   stack is doing and you do not care at all as long as your suspend
   blocker scheme makes things work somehow.
  
 
  Yes I don't know everything our user-space stack is doing, but I do
  know that it makes many calls between processes (and in both
  directions). As far as I know it uses timeouts when calling into
  untrusted code, so a misbehaving application will cause an error
  dialog to pop up asking if the user if it should wait longer or
  terminate the application.
 
  Sigh, the more I learn about the details of android and it's violation
  of all sane engineering principles the more I understand why you
  invented a huge nail to push through all layers in order to bring the
  system into idle at all. And yes, you need a sledge hammer to drive
  that big nail through everything, so you are using the right tool.
 
  Seriously, the cross app call goes through your framework, which
  already knows, that the untrusted part is frozen. So it can deal
  nicely with it in any way you want including unfreezing.
 
 Cross app calls do not go through a central process.

Well, yeah.

Arve, we're still learning you have some more requirements we had no idea
about before and such that _only_ the suspend blockers (or wakelocks) framework
is suitable to satisfy them.  I don't realistically think we can make any
progress this way.

   Up to that point, I really tried hard to step back from my initial
   OMG, promoting crap is a nono reaction and work with you on a
   sensible technical solution to confine crap and make it aligned with
   other efforts in this area.
  
   So now, after I spent a reasonable amount of time (as you did) to
   understand what your 

Re: suspend blockers Android integration

[Arjan van de Ven]

On Sat, 5 Jun 2010 15:26:36 -0700
Brian Swetland swetl...@google.com wrote:

 
 I'm continually surprised by answers like this.  We run on hardware
 that power gates very aggressively and draws in the neighborhood of
 1-2mA at the battery when in the lowest state (3-5mA while the radio
 is connected to the network and paging).  Waking up out of that lowest
 state and executing code every few seconds or (worse) several times a
 second) will raise your average power consumption.  Being able to stay
 parked at the very bottom for minutes or hours at a time when nothing
 interesting is happening is very useful and can have a significant
 impact on overall battery life.

It's relatively simple math.

If you wake up for a burst of work, you burn power at the higher level
P1 (versus the lower power level P2), for, lets say an average time T,
with a relatively small T (few milliseconds at most).

If you wake up X times per second (with X being a fractional number, so
can be smaller than 1) the extra power consumption factor is

  X * T * P1
---
X * T * P1 + (1.0 - X * T) * P2

if you draw a graph of this, for real values of P and T, there's a real
point where you hit diminishing returns.

if say T is 5 milliseconds (that's a high amount), and X is 1
wakeup/second, then there's already a 200:1 ratio in time an power.

If X goes to once every 10 seconds (not unreasonable, especially since
any real device will pull email and stuff in the backgroudn), you have
2000:1 time and power ratios...

Unless your on power is insane high (and hopefully it's not, since
you're not turning on the whole device obviously, you do selective
power and clock gating)... that divide by 200 or 2000 makes the whole
problem go away.. in the seconds range for really low power devices.
Not in hours range. 


On laptops (which have much more poor powermanagement) this point is
around 40 milliseconds or so.. but on phone silicon that I've seen,
both Intel and others, this is in the 1 to 5 seconds range.





-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Rafael J. Wysocki]

On Sunday 06 June 2010, Brian Swetland wrote:
 On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:
 
  We clearly have different standards for what we consider good. We
  measure time suspended in minutes or hours, not seconds, and waking up
  every second or two causes a noticeable decrease in battery life on
  the hardware we have today.
 
  I guess I'm spoiled working with (unreleased) hardware that knows how
  to power gate ;-)
 
 I'm continually surprised by answers like this.  We run on hardware
 that power gates very aggressively and draws in the neighborhood of
 1-2mA at the battery when in the lowest state (3-5mA while the radio
 is connected to the network and paging).  Waking up out of that lowest
 state and executing code every few seconds or (worse) several times a
 second) will raise your average power consumption.  Being able to stay
 parked at the very bottom for minutes or hours at a time when nothing
 interesting is happening is very useful and can have a significant
 impact on overall battery life.

Yes, and if you look at the approach I proposed in this very thread
(http://lkml.org/lkml/2010/6/4/368), it goes exactly in this direction.

And I think it is superior to the opportunistic suspend framework you have
right now, because, for example, it doesn't require you to carry out full
system resume and full system suspend every once a while to check battery
status.

And guess what, suspending and resuming the whole system actually uses energy.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Rafael J. Wysocki]

On Sunday 06 June 2010, Arve Hjønnevåg wrote:
 2010/6/5 Rafael J. Wysocki r...@sisk.pl:
  On Saturday 05 June 2010, Arve Hjønnevåg wrote:
  2010/6/4 Matt Helsley matth...@us.ibm.com:
   On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
   On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
   wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
  
   snip
  
  
With the cgroup freezer you can suspend them right away and
just keep the trusted background task(s) alive which allows us to
go into deeper idle states instead of letting the crapplications
run unconfined until the download finished and the suspend
blocker goes away.
   
  
   Yes this would be better, but I want it in addition to suspend, not
   instead of it. It is also unclear if our user-space code could easily
   make use of it since our trusted code calls into untrusted code.
  
  
   Perhaps I'm misunderstanding, but suspend and the cgroup freezer
   interoperate well today -- you don't have to choose one or the other.
   If you've discovered otherwise I'd consider it a bug and would like to
   hear more about it.
  
 
  I'm not aware of any bug with combining both, but we cannot use
  suspend at all without suspend blockers in the kernel (since wakeup
  events may be ignored)
 
  The more I think of it, the more it appears to me that the problem of
  lost wakeup events can actually be solved without suspend blockers.
  I'll send a bunch of patches to address this issue, probably tomorrow.
 
 
 I know of two ways to prevent lost wakeup events. Reset a timeout
 every time you receive a wakeup event or prevents suspend until you
 know the event has been fully processed. Does your solution fall onto
 one of these two categories, or do you have a third way?

Basically, it involves two mechanisms, detection of wakeup events occuring
right before suspend is started and aborting suspend if wakeup events occur
in the middle of it.

  and I don't know how we can safely freeze
  cgroups without funneling all potential wakeup events through a
  process that never gets frozen.
 
  If your untrusted apps get called by the trusted ones, they aren't really
  untrusted in the first place.
 
 That is not a correct statement. A trusted apps can call into an
 untrusted app, it just has to validate the response and handle not
 getting a response at all. There are also different levels of trust. I
 may have trusted an app to provide a contact pictures, but not trusted
 it to block suspend. When the phone rings the app will be called to
 provide the picture for the incoming call dialog, but if it is frozen
 at this point the more trusted app that handles the incoming phone
 call will not be able to get the picture.

It will be able to do that if it causes the frozen part of user space to be
thawed.

I think you have this problem already, though, because you use full system
suspend and all of your apps are frozen by it.  So, to handle the situation you
describe above, you need to carry out full system resume that will thaw the
tasks for you.  I don't see any fundamental difference betwee the two cases.

  From what you're saying it follows that you're not really willing to accept
  any solution different to your suspend blockers.  Is that really the case?
 
 I don't think that is a fair way to put it. We need to support our
 user-space framework and I have not seen an alternative solution that
 clearly will work (other than replacing suspend_blockers with pm_qos
 constraints that do the same thing).

Then think again of the approach I proposed and explain to me why it won't
work, because I haven't seen any convincing argument on that yet.

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Thomas Gleixner t...@linutronix.de:
 On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
   Why is it a BUG in the trusted app, when I initiate a download and put
   the phone down ?
  
 
  It is not, but we have had bugs where a trusted app does not unblock
  suspend after some failure case where it is no longer making any
  progress.
 
  Well, that's simply an application bug which sucks battery with or
  without suspend blockers. So it's unrelated to the freezing of
  untrusted apps while a trusted app still works in the background
  before allowing the machine to suspend.
 

 It is not unrelated if the trusted app has stopped working but still
 blocks suspend. The battery drains when you combine them.

 What you are describing is a problem which is not solvable either way.
 If you take the lock and do not release it you're not going to
 suspend. I never claimed that any other mechanism resolves this.

Whether you claimed it or not, this is the only case where using
cgroups would have a significant power saving over what we get with
suspend. The trusted app is idle and the untrusted app is frozen, so
we enter a low power mode from idle.

 But this is not related to the fact that freezing crap while running a
 sane background task is going to save you power vs. an approach where
 running a sane background task allows crap to consume power unconfined
 until it is done.

If the task that is blocking suspend is using the cpu anyway, then the
bad app does not increase the power consumption nearly as much as if
the task that blocked suspend is idle.

   That download might take a minute or two, but that's not an
   justification for the crapplication to run unconfined and prevent
   lower power states.
  
 
  I agree, but this is not a simple problem to solve.
 
  Not with suspend blockers, but with cgroup confinement of crap, it's
  straight forward.
 

 I don't think is is straight forward. If the a process in the frozen
 group holds a resource that a process in the unfrozen group needs, how
 do deal with that?

 I'm going to fix the framework which puts the group into freeze state
 w/o making sure that there is no held shared resource. Come on it's
 not rocket science.


I'm not sure which framework you are talking about here, but I don't
think there is a single framework that knows about all shared
resources.

  Yes I don't know everything our user-space stack is doing, but I do
  know that it makes many calls between processes (and in both
  directions). As far as I know it uses timeouts when calling into
  untrusted code, so a misbehaving application will cause an error
  dialog to pop up asking if the user if it should wait longer or
  terminate the application.
 
  Sigh, the more I learn about the details of android and it's violation
  of all sane engineering principles the more I understand why you
  invented a huge nail to push through all layers in order to bring the
  system into idle at all. And yes, you need a sledge hammer to drive
  that big nail through everything, so you are using the right tool.
 
  Seriously, the cross app call goes through your framework, which
  already knows, that the untrusted part is frozen. So it can deal
  nicely with it in any way you want including unfreezing.

 Cross app calls do not go through a central process.

 It's not about a central process, it goes through your framework,
 which should be able to deal with it. If not, it's a design failure
 which needs to be fixed at the place where the failure happened.

 
  How can it be fixed? The user presses the back button, the framework
  determines that app A is in the foreground and send the key to app A,
  app A decides that it it does not have anything internal to go back to
  and tells the framework to switch back to the previous app. If the
  user presses the back key again, the framework does not know which app
  this key should go to until app A has finished processing the first
  key press.
 
  Errm, what has this to do with frozen apps? If your system is
  handling input events then there are no frozen apps and even if they
  are frozen your framework can unfreeze them _before_ talking to them.
 
  So which unfixable problem are you describing with the above example ?
 

 You are claiming that trusted code should not have any dependencies on
 untrusted code. I gave you a visible example of such a dependency and
 want you to tell me how you can avoid this dependency. Since you are
 claiming that our user-space framework is fundamentally broken if it
 has to wait for untrusted code, I don't think it is unreasonable for
 you to answer this. Or do you think it is valid to communicate with
 untrusted code when the screen is on but not when it is off.

 It does not matter whether the screen is off or not. If you need to
 call into that untrusted app from your trusted app and you know about
 the might be frozen 

Re: suspend blockers Android integration

[Arjan van de Ven]

On Sat, 5 Jun 2010 15:39:44 -0700
Arve Hjønnevåg a...@android.com wrote:

 
  For example if the Adobe Flash player puts a timer every 10
  milliseconds (yes it does that), and you give it a 3.99 seconds
  range, it will fire its timers every 4 seconds unless other
  activity happens independently, at which point it'll align with
  that instead.
 
 
 If you do that what you are delivering is nowhere close to what the
 app asked for. 

yeah it feels a little bit suspended 

 You don't need range timers for this, you could just as
 well add 4 seconds to all normal timers.

.. with the difference that with range timers, you naturally align with
other activity, so if there's system level activity, the AVERAGE service
the app gets is better by a LOT than just adding 4 seconds always.

but you knew that just doesn't help your case.



-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Rafael J. Wysocki]

On Sunday 06 June 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
  2010/6/5 Thomas Gleixner t...@linutronix.de:
   B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
  So taking your example:
 
  Event happens and gets delivered to the framework
 
   framework selects A because it is in the foreground
 
   if (A is frozen)
  unfreeze(A)
 
   deliver_event_to(A)
 
  It's that simple.
 
 
 That is too simple. You also have to prevent A from being frozen while
 it is processing the event or the result would be the same as if it
 was frozen beforehand.

Well, the freezing of the untrusted part of user space needs to be triggered
somehow in the first place.  Whatever mechanism is used for that, there should
be a way to tell it to not to freeze the untrusted part of user space for a
while.  Yes, it is similar to wakelocks, but I think it can be implemented
entirely in user space.

So, in general, the trusted app that needs an untrusted one to handle stuff
will take a freeze lock to prevent the power manager from freezing the
untrusted part of user space (that will also cause it to thaw these tasks if
they are frozen at the moment) and will release the freeze lock when it's
done with its job.  You can use timeouts and whatever you like with that and
the kernel doesn't have to participate in that (except for carrying out the
low-level freezing and thawing of the untrusted tasks at the power manager's
request).

Rafael
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Thomas Gleixner]

On Sat, 5 Jun 2010, Arjan van de Ven wrote:

 On Sat, 5 Jun 2010 15:26:36 -0700
 Brian Swetland swetl...@google.com wrote:
 
  
  I'm continually surprised by answers like this.  We run on hardware
  that power gates very aggressively and draws in the neighborhood of
  1-2mA at the battery when in the lowest state (3-5mA while the radio
  is connected to the network and paging).  Waking up out of that lowest
  state and executing code every few seconds or (worse) several times a
  second) will raise your average power consumption.  Being able to stay
  parked at the very bottom for minutes or hours at a time when nothing
  interesting is happening is very useful and can have a significant
  impact on overall battery life.
 
 It's relatively simple math.
 
 If you wake up for a burst of work, you burn power at the higher level
 P1 (versus the lower power level P2), for, lets say an average time T,
 with a relatively small T (few milliseconds at most).
 
 If you wake up X times per second (with X being a fractional number, so
 can be smaller than 1) the extra power consumption factor is
 
   X * T * P1
 ---
 X * T * P1 + (1.0 - X * T) * P2
 
 if you draw a graph of this, for real values of P and T, there's a real
 point where you hit diminishing returns.
 
 if say T is 5 milliseconds (that's a high amount), and X is 1
 wakeup/second, then there's already a 200:1 ratio in time an power.
 
 If X goes to once every 10 seconds (not unreasonable, especially since
 any real device will pull email and stuff in the backgroudn), you have
 2000:1 time and power ratios...
 
 Unless your on power is insane high (and hopefully it's not, since
 you're not turning on the whole device obviously, you do selective
 power and clock gating)... that divide by 200 or 2000 makes the whole
 problem go away.. in the seconds range for really low power devices.
 Not in hours range. 

That's the whole problem. Suspend blockers are a binary all on/off
approach so you waste power just to get the thing back to
suspend. They unleash the world and some more just to put it back
into oblivion with brute force.

Thanks,

tglx
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Rafael J. Wysocki r...@sisk.pl:
 On Saturday 05 June 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
 
  2010/6/4 Thomas Gleixner t...@linutronix.de:
   Arve,
  
   On Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
  
   On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
   wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
I kind of agree here, so I'd like to focus a bit on that.
   
Here's my idea in the very general terms:
   
(1) Use the cgroup freezer to suspend the untrusted apps (ie. 
the ones
    that don't use suspend blockers aka wakelocks in the Android 
world) at the
    point Android would normally start opportunistic suspend.
   
There is an additional benefit to this approach:
   
    In the current android world a background task (e.g. download
    initiated before the screensaver kicked in) prevents the suspend,
    but that also means that the crapplications can still suck power
    completely unconfined.
   
  
   Yes this can happen. It is usually only a big problem when you combine
   an (trusted) application that has a bug that blocks suspend forever
   with an application that wakes up too often for us to enter low power
   idle modes.
  
   Why is it a BUG in the trusted app, when I initiate a download and put
   the phone down ?
  
 
  It is not, but we have had bugs where a trusted app does not unblock
  suspend after some failure case where it is no longer making any
  progress.
 
  Well, that's simply an application bug which sucks battery with or
  without suspend blockers. So it's unrelated to the freezing of
  untrusted apps while a trusted app still works in the background
  before allowing the machine to suspend.
 

 It is not unrelated if the trusted app has stopped working but still
 blocks suspend. The battery drains when you combine them.

   That download might take a minute or two, but that's not an
   justification for the crapplication to run unconfined and prevent
   lower power states.
  
 
  I agree, but this is not a simple problem to solve.
 
  Not with suspend blockers, but with cgroup confinement of crap, it's
  straight forward.
 

 I don't think is is straight forward. If the a process in the frozen
 group holds a resource that a process in the unfrozen group needs, how
 do deal with that?

 That depends a good deal on what you mean by holding a resource.


I'm not sure why that matters. Any resource held by a frozen process
could cause problems whether it is something like being the current
foreground app or a mutex in shared memory.

 Generally, however, if your trusted processes depend on the processes you
 don't trust, then either the former should not be trusted, or the latter 
 should
 be trusted.

There are different levels of trust. Trusted processes often need to
wait for an untrusted process to release a resource for the untrusted
process to behave correctly, but the trusted process can revoke the
resource if the untrusted process does not comply in time.

    With the cgroup freezer you can suspend them right away and
    just keep the trusted background task(s) alive which allows us to
    go into deeper idle states instead of letting the crapplications
    run unconfined until the download finished and the suspend
    blocker goes away.
   
  
   Yes this would be better, but I want it in addition to suspend, not
   instead of it. It is also unclear if our user-space code could easily
   make use of it since our trusted code calls into untrusted code.
  
   Sorry, that's really the worst argument I saw in this whole
   discussion.
  
   You're basically saying, that you have no idea what your user space
   stack is doing and you do not care at all as long as your suspend
   blocker scheme makes things work somehow.
  
 
  Yes I don't know everything our user-space stack is doing, but I do
  know that it makes many calls between processes (and in both
  directions). As far as I know it uses timeouts when calling into
  untrusted code, so a misbehaving application will cause an error
  dialog to pop up asking if the user if it should wait longer or
  terminate the application.
 
  Sigh, the more I learn about the details of android and it's violation
  of all sane engineering principles the more I understand why you
  invented a huge nail to push through all layers in order to bring the
  system into idle at all. And yes, you need a sledge hammer to drive
  that big nail through everything, so you are using the right tool.
 
  Seriously, the cross app call goes through your framework, which
  already knows, that the untrusted part is frozen. So it can deal
  nicely with it in any way you want including unfreezing.

 Cross app calls do not go through a central process.

 Well, yeah.

 Arve, we're still learning you have some more requirements we had no idea

What new requirement 

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Arjan van de Ven ar...@infradead.org:
 On Sat, 5 Jun 2010 15:39:44 -0700
 Arve Hjønnevåg a...@android.com wrote:

 
  For example if the Adobe Flash player puts a timer every 10
  milliseconds (yes it does that), and you give it a 3.99 seconds
  range, it will fire its timers every 4 seconds unless other
  activity happens independently, at which point it'll align with
  that instead.
 

 If you do that what you are delivering is nowhere close to what the
 app asked for.

 yeah it feels a little bit suspended

 You don't need range timers for this, you could just as
 well add 4 seconds to all normal timers.

 .. with the difference that with range timers, you naturally align with
 other activity, so if there's system level activity, the AVERAGE service
 the app gets is better by a LOT than just adding 4 seconds always.

 but you knew that just doesn't help your case.

So you are saying it is safe to use range timers to radically change
the requested timer interval because it does not actually get to the
value that you changed it so. But you are also saying that this will
allow the system to stay idle for that long. Something does not add
up.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Thomas Gleixner]

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's not an
justification for the crapplication to run unconfined and prevent
lower power states.
   
  
   I agree, but this is not a simple problem to solve.
  
   Not with suspend blockers, but with cgroup confinement of crap, it's
   straight forward.
  
 
  I don't think is is straight forward. If the a process in the frozen
  group holds a resource that a process in the unfrozen group needs, how
  do deal with that?
 
  I'm going to fix the framework which puts the group into freeze state
  w/o making sure that there is no held shared resource. Come on it's
  not rocket science.
 
 
 I'm not sure which framework you are talking about here, but I don't
 think there is a single framework that knows about all shared
 resources.

Damn, it's not me talking about our framework, you are mentioning
when it fits your needs.

If you do not have a clearly defined user space framework, then we
talk about a completely random conglomeration of applications which
need to be brought into submission by some global brute force
approach.

I'm tired of this, really. You just use terminlology as it fits to
defend the complete design failure of android. But you fail to trick
me :)

Can you please explain in a consistent way how the application stack
and the underlying framework (which exists according to android docs)
is handling events and how the separation of trust level works ?

We need to know that, otherwise we turn in circles forever.

Thanks,

tglx

Re: suspend blockers Android integration

[Thomas Gleixner]

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
   Well, that's simply an application bug which sucks battery with or
   without suspend blockers. So it's unrelated to the freezing of
   untrusted apps while a trusted app still works in the background
   before allowing the machine to suspend.
  
 
  It is not unrelated if the trusted app has stopped working but still
  blocks suspend. The battery drains when you combine them.
 
  What you are describing is a problem which is not solvable either way.
  If you take the lock and do not release it you're not going to
  suspend. I never claimed that any other mechanism resolves this.
 
 Whether you claimed it or not, this is the only case where using
 cgroups would have a significant power saving over what we get with
 suspend. The trusted app is idle and the untrusted app is frozen, so
 we enter a low power mode from idle.

Nothing else was what I said and depending on the usage pattern this
can be significant. Just you converted a perfectly sensible technical
argument into a quibble about BUGs in applicatins which are not
confinable by defintion.
 
  But this is not related to the fact that freezing crap while running a
  sane background task is going to save you power vs. an approach where
  running a sane background task allows crap to consume power unconfined
  until it is done.
 
 If the task that is blocking suspend is using the cpu anyway, then the
 bad app does not increase the power consumption nearly as much as if
 the task that blocked suspend is idle.

That's utter bullshit. If the app missed to release the supsend
blocker then your crappy while(1); app is killing you in no time,
while the same frozen crappy while(1); does no harm at all.
 
Thanks,

tglx

Re: suspend blockers Android integration

[Thomas Gleixner]

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
  2010/6/5 Thomas Gleixner t...@linutronix.de:
   B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
  Cross app calls do not go through a central process.
 
  It's not about a central process, it goes through your framework,
  which should be able to deal with it. If not, it's a design failure
  which needs to be fixed at the place where the failure happened.
 
  
   How can it be fixed? The user presses the back button, the framework
   determines that app A is in the foreground and send the key to app A,
   app A decides that it it does not have anything internal to go back to
   and tells the framework to switch back to the previous app. If the
   user presses the back key again, the framework does not know which app
   this key should go to until app A has finished processing the first
   key press.
  
   Errm, what has this to do with frozen apps? If your system is
   handling input events then there are no frozen apps and even if they
   are frozen your framework can unfreeze them _before_ talking to them.
  
   So which unfixable problem are you describing with the above example ?
  
 
  You are claiming that trusted code should not have any dependencies on
  untrusted code. I gave you a visible example of such a dependency and
  want you to tell me how you can avoid this dependency. Since you are
  claiming that our user-space framework is fundamentally broken if it
  has to wait for untrusted code, I don't think it is unreasonable for
  you to answer this. Or do you think it is valid to communicate with
  untrusted code when the screen is on but not when it is off.
 
  It does not matter whether the screen is off or not. If you need to
  call into that untrusted app from your trusted app and you know about
  the might be frozen state then you can deal with it.
 
  So taking your example:
 
  Event happens and gets delivered to the framework
 
       framework selects A because it is in the foreground
 
       if (A is frozen)
          unfreeze(A)
 
       deliver_event_to(A)
 
  It's that simple.
 
 
 That is too simple. You also have to prevent A from being frozen while
 it is processing the event or the result would be the same as if it
 was frozen beforehand.

The framework decides when to freeze the app in the first place (as
your framework does now when it decides to suspend)
 
 So it knows whether the app is frozen or not.

 So it knows damend well whether it processed the event or not.

Thanks,

tglx
 

Re: suspend blockers Android integration

[Arve Hjønnevåg]

On Sat, Jun 5, 2010 at 3:48 PM, Arjan van de Ven ar...@infradead.org wrote:
 On Sat, 5 Jun 2010 15:26:36 -0700
 Brian Swetland swetl...@google.com wrote:


 I'm continually surprised by answers like this.  We run on hardware
 that power gates very aggressively and draws in the neighborhood of
 1-2mA at the battery when in the lowest state (3-5mA while the radio
 is connected to the network and paging).  Waking up out of that lowest
 state and executing code every few seconds or (worse) several times a
 second) will raise your average power consumption.  Being able to stay
 parked at the very bottom for minutes or hours at a time when nothing
 interesting is happening is very useful and can have a significant
 impact on overall battery life.

 It's relatively simple math.

 If you wake up for a burst of work, you burn power at the higher level
 P1 (versus the lower power level P2), for, lets say an average time T,
 with a relatively small T (few milliseconds at most).

 If you wake up X times per second (with X being a fractional number, so
 can be smaller than 1) the extra power consumption factor is

          X * T * P1
 ---
 X * T * P1 + (1.0 - X * T) * P2

 if you draw a graph of this, for real values of P and T, there's a real
 point where you hit diminishing returns.

 if say T is 5 milliseconds (that's a high amount), and X is 1
 wakeup/second, then there's already a 200:1 ratio in time an power.


It is a 200:1 ratio in time not in power.

 If X goes to once every 10 seconds (not unreasonable, especially since
 any real device will pull email and stuff in the backgroudn), you have
 2000:1 time and power ratios...

 Unless your on power is insane high (and hopefully it's not, since

The absolute on power is not relevant to the ratio, the difference
between on and off power is. This can easily be 100:1.

 you're not turning on the whole device obviously, you do selective
 power and clock gating)... that divide by 200 or 2000 makes the whole
 problem go away.. in the seconds range for really low power devices.
 Not in hours range.


If you improve the low power state, compared to the on state wakeup
gets worse, not better, but yes the phone hardware we have now does
not need to stay idle for hours to get good battery life, the msm
hardware at least needs to stay idle for more than a few seconds.


 On laptops (which have much more poor powermanagement) this point is
 around 40 milliseconds or so.. but on phone silicon that I've seen,
 both Intel and others, this is in the 1 to 5 seconds range.





 --
 Arjan van de Ven        Intel Open Source Technology Centre
 For development, discussion and tips for power savings,
 visit http://www.lesswatts.org




-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Rafael J. Wysocki r...@sisk.pl:
 On Sunday 06 June 2010, Arve Hjønnevåg wrote:
 2010/6/5 Rafael J. Wysocki r...@sisk.pl:
  On Saturday 05 June 2010, Arve Hjønnevåg wrote:
  2010/6/4 Matt Helsley matth...@us.ibm.com:
   On Fri, Jun 04, 2010 at 05:39:17PM -0700, Arve Hjønnevåg wrote:
   On Fri, Jun 4, 2010 at 5:05 PM, Thomas Gleixner t...@linutronix.de 
   wrote:
On Sat, 5 Jun 2010, Rafael J. Wysocki wrote:
  
   snip
  
  
    With the cgroup freezer you can suspend them right away and
    just keep the trusted background task(s) alive which allows us to
    go into deeper idle states instead of letting the crapplications
    run unconfined until the download finished and the suspend
    blocker goes away.
   
  
   Yes this would be better, but I want it in addition to suspend, not
   instead of it. It is also unclear if our user-space code could easily
   make use of it since our trusted code calls into untrusted code.
  
  
   Perhaps I'm misunderstanding, but suspend and the cgroup freezer
   interoperate well today -- you don't have to choose one or the other.
   If you've discovered otherwise I'd consider it a bug and would like to
   hear more about it.
  
 
  I'm not aware of any bug with combining both, but we cannot use
  suspend at all without suspend blockers in the kernel (since wakeup
  events may be ignored)
 
  The more I think of it, the more it appears to me that the problem of
  lost wakeup events can actually be solved without suspend blockers.
  I'll send a bunch of patches to address this issue, probably tomorrow.
 

 I know of two ways to prevent lost wakeup events. Reset a timeout
 every time you receive a wakeup event or prevents suspend until you
 know the event has been fully processed. Does your solution fall onto
 one of these two categories, or do you have a third way?

 Basically, it involves two mechanisms, detection of wakeup events occuring
 right before suspend is started

This sounds like the timeout approach which I thought you did not like.

 and aborting suspend if wakeup events occur
 in the middle of it.

Aborting suspend is easy, but when do you allow suspend again?

  and I don't know how we can safely freeze
  cgroups without funneling all potential wakeup events through a
  process that never gets frozen.
 
  If your untrusted apps get called by the trusted ones, they aren't really
  untrusted in the first place.
 
 That is not a correct statement. A trusted apps can call into an
 untrusted app, it just has to validate the response and handle not
 getting a response at all. There are also different levels of trust. I
 may have trusted an app to provide a contact pictures, but not trusted
 it to block suspend. When the phone rings the app will be called to
 provide the picture for the incoming call dialog, but if it is frozen
 at this point the more trusted app that handles the incoming phone
 call will not be able to get the picture.

 It will be able to do that if it causes the frozen part of user space to be
 thawed.

 I think you have this problem already, though, because you use full system
 suspend and all of your apps are frozen by it.  So, to handle the situation 
 you
 describe above, you need to carry out full system resume that will thaw the
 tasks for you.  I don't see any fundamental difference betwee the two cases.


Yes, we can keep all our user space suspend blockers and thaw the
frozen cgroup when any suspend blocker is held, but this would
eliminate any power advantage that freezing a cgroup has over using
suspend to freeze all processes. Without annotating the drivers to
block the cgroup freezing in the same places as we now block suspend,
it also prevents processes in the cgroup that we freeze from directly
consuming wakup events.

  From what you're saying it follows that you're not really willing to accept
  any solution different to your suspend blockers.  Is that really the case?
 
 I don't think that is a fair way to put it. We need to support our
 user-space framework and I have not seen an alternative solution that
 clearly will work (other than replacing suspend_blockers with pm_qos
 constraints that do the same thing).

 Then think again of the approach I proposed and explain to me why it won't
 work, because I haven't seen any convincing argument on that yet.


If you are referring to the approach that we don't use suspend but
freeze a cgroup instead, this only solves the problem of bad apps. It
does not help pause timers in trusted user space code and in the
kernel, so it does not lower our average power consumption. And, it
does not solve the problem for systems that enters lower power states
from suspend than it can from idle. The last point my not be relevant
to android anymore, but desktop systems already have auto suspend and
it would be preferable to have a race free kernel api for this.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a 

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Thomas Gleixner t...@linutronix.de:
 On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might take a minute or two, but that's not an
justification for the crapplication to run unconfined and prevent
lower power states.
   
  
   I agree, but this is not a simple problem to solve.
  
   Not with suspend blockers, but with cgroup confinement of crap, it's
   straight forward.
  
 
  I don't think is is straight forward. If the a process in the frozen
  group holds a resource that a process in the unfrozen group needs, how
  do deal with that?
 
  I'm going to fix the framework which puts the group into freeze state
  w/o making sure that there is no held shared resource. Come on it's
  not rocket science.
 

 I'm not sure which framework you are talking about here, but I don't
 think there is a single framework that knows about all shared
 resources.

 Damn, it's not me talking about our framework, you are mentioning
 when it fits your needs.

You said you were going to fix the framework. I did know if you were
talking about the cgroup framework, or the android user-space
frameworks. I don't think either has knowledge about all shared
resources.


 If you do not have a clearly defined user space framework, then we
 talk about a completely random conglomeration of applications which
 need to be brought into submission by some global brute force
 approach.

 I'm tired of this, really. You just use terminlology as it fits to
 defend the complete design failure of android. But you fail to trick
 me :)

 Can you please explain in a consistent way how the application stack
 and the underlying framework (which exists according to android docs)
 is handling events and how the separation of trust level works ?


I don't think I can, since I only know small parts of it. I know some
events like input event go though a single thread in our system
process, while other events like network packets (which are also
wakeup events) goes directly to the app.

 We need to know that, otherwise we turn in circles forever.

 Thanks,

        tglx



-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Thomas Gleixner t...@linutronix.de:
 On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
   Well, that's simply an application bug which sucks battery with or
   without suspend blockers. So it's unrelated to the freezing of
   untrusted apps while a trusted app still works in the background
   before allowing the machine to suspend.
  
 
  It is not unrelated if the trusted app has stopped working but still
  blocks suspend. The battery drains when you combine them.
 
  What you are describing is a problem which is not solvable either way.
  If you take the lock and do not release it you're not going to
  suspend. I never claimed that any other mechanism resolves this.
 
 Whether you claimed it or not, this is the only case where using
 cgroups would have a significant power saving over what we get with
 suspend. The trusted app is idle and the untrusted app is frozen, so
 we enter a low power mode from idle.

 Nothing else was what I said and depending on the usage pattern this
 can be significant. Just you converted a perfectly sensible technical
 argument into a quibble about BUGs in applicatins which are not
 confinable by defintion.

  But this is not related to the fact that freezing crap while running a
  sane background task is going to save you power vs. an approach where
  running a sane background task allows crap to consume power unconfined
  until it is done.
 
 If the task that is blocking suspend is using the cpu anyway, then the
 bad app does not increase the power consumption nearly as much as if
 the task that blocked suspend is idle.

 That's utter bullshit. If the app missed to release the supsend
 blocker then your crappy while(1); app is killing you in no time,
 while the same frozen crappy while(1); does no harm at all.

This is the bug I described above. If the app that blocked suspend did
not release the suspend blocker and went idle, then another while(1)
app will drain the battery. If the app that blocked suspend only
blocked suspend while it needs to run (which is the typical reason to
block suspend) then the system is not idle anyway and the impact of
the while(1) app is much less severe.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Arve Hjønnevåg]

2010/6/5 Thomas Gleixner t...@linutronix.de:
 On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
 2010/6/5 Thomas Gleixner t...@linutronix.de:
  On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
  2010/6/5 Thomas Gleixner t...@linutronix.de:
   B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
  Cross app calls do not go through a central process.
 
  It's not about a central process, it goes through your framework,
  which should be able to deal with it. If not, it's a design failure
  which needs to be fixed at the place where the failure happened.
 
  
   How can it be fixed? The user presses the back button, the framework
   determines that app A is in the foreground and send the key to app A,
   app A decides that it it does not have anything internal to go back to
   and tells the framework to switch back to the previous app. If the
   user presses the back key again, the framework does not know which app
   this key should go to until app A has finished processing the first
   key press.
  
   Errm, what has this to do with frozen apps? If your system is
   handling input events then there are no frozen apps and even if they
   are frozen your framework can unfreeze them _before_ talking to them.
  
   So which unfixable problem are you describing with the above example ?
  
 
  You are claiming that trusted code should not have any dependencies on
  untrusted code. I gave you a visible example of such a dependency and
  want you to tell me how you can avoid this dependency. Since you are
  claiming that our user-space framework is fundamentally broken if it
  has to wait for untrusted code, I don't think it is unreasonable for
  you to answer this. Or do you think it is valid to communicate with
  untrusted code when the screen is on but not when it is off.
 
  It does not matter whether the screen is off or not. If you need to
  call into that untrusted app from your trusted app and you know about
  the might be frozen state then you can deal with it.
 
  So taking your example:
 
  Event happens and gets delivered to the framework
 
       framework selects A because it is in the foreground
 
       if (A is frozen)
          unfreeze(A)
 
       deliver_event_to(A)
 
  It's that simple.
 

 That is too simple. You also have to prevent A from being frozen while
 it is processing the event or the result would be the same as if it
 was frozen beforehand.

 The framework decides when to freeze the app in the first place (as
 your framework does now when it decides to suspend)

     So it knows whether the app is frozen or not.

     So it knows damend well whether it processed the event or not.


Our user-space code is not single-threaded. So just because an app was
not frozen when you checked does not mean it will remain unfrozen. We
can use the same user-space wakelock api we have now to prevent
freezing apps instead of preventing suspend, but we loose any
advantage we get from freezing just a subset of processes this way.

-- 
Arve Hjønnevåg
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suspend blockers Android integration

[Alan Stern]

On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:

 Yes, we can keep all our user space suspend blockers and thaw the
 frozen cgroup when any suspend blocker is held, but this would
 eliminate any power advantage that freezing a cgroup has over using
 suspend to freeze all processes. Without annotating the drivers to
 block the cgroup freezing in the same places as we now block suspend,
 it also prevents processes in the cgroup that we freeze from directly
 consuming wakup events.

The driver annotations don't need to block the cgroup freezing.  They
just need to keep the system running long enough to awaken a thread
that will handle the wakeup event.  (See below.)  A pm-qos constraint 
is good enough for this.

 If you are referring to the approach that we don't use suspend but
 freeze a cgroup instead, this only solves the problem of bad apps. It
 does not help pause timers in trusted user space code and in the
 kernel, so it does not lower our average power consumption.

You can solve this problem if you restructure your trusted apps in
the right way.  Require a trusted app to guarantee that whenever it
doesn't hold any suspend blockers, it will do nothing but wait (in a
poll() system call for example) for a wakeup event.  When the event
occurs, it must then activate a suspend blocker.

Better yet, make it more fine-grained.  Instead of trusted apps, have
trusted threads.  Freeze the untrusted threads along with everything
else, and require the trusted threads to satisfy this guarantee.

In this way, while the system is idle no user timers will get renewed.
Kernel timers are another matter, but we should be able to handle them.  
There's nothing Android-specific about wanting to reduce kernel timer 
wakeups while in a low-power mode.

 And, it
 does not solve the problem for systems that enters lower power states
 from suspend than it can from idle. The last point my not be relevant
 to android anymore, but desktop systems already have auto suspend and
 it would be preferable to have a race free kernel api for this.

This is an entirely different matter from the rest of the discussion.
It would be better to consider this separately after Android's current
problems have been addressed.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html