From: James Bottomley on
On Sun, 2010-08-01 at 16:40 -0400, Ted Ts'o wrote:
> This brings me back to a major problem I have with the pm_qos approach
> to power management. It assumes that applications know best, and that
> they should be free to tell pm_qos subsystem whether they need 0ms
> latency for wireless.

Um, so this behaviour is isomorphic to the suspend block case for the
applications. I think everyone agrees that suspend block isn't optimal,
but we were prepared to use it as a starting point given the lack of
enthusiasm in android for the more innovative approaches that have been
proposed.

> Right now, I can't even query the pm_qos
> subsystem to see which application is responsible for keeping the
> wireless on 100% of the time!

That's hardly a fair criticism: this is easily fixable but the people
looking into it have other calls on their time. At least you got some of
the basic problems (like init from atomic context and sort efficiency)
fixed this time around. If some large organisation actually cared
enough to contribute code, we might be moving faster ....

> And even if I could find out, maybe
> some power management framework should be allowed to give a override
> to the application's wishes. OK, maybe the Opera web browser is
> requesting the very best wireless QOS because it wants to beat Chrome
> on some silly potato benchmark --- well, it's ***stupid*** to say that
> my power management should be a one-size-fits all because applications
> should be always as power efficient as possible whether they are
> connected to AC mains or I have a 800mWh cell phone battery. Worse
> yet, it's stupid to say that the application should have the last
> word. Darn it, *I* own the mobile device, and I (or my proxy, which
> might be the Android OS, or some power manage daemon) should be able
> to say, "I don't care what the application claimed it wanted for power
> QOS --- it's not getting more than 100ms wireless latency, and that's
> final."

That's why you present the user with choices and report on the outcomes.
At the end of the day the choice becomes binary: if the mobile optimised
browser burns you battery on the power meter, users will either
uninstall and move on to the next browser or deny the current browser
the ability to block suspend.

> And note that this is something that might even change over time, or
> depending on circumstances. Maybe normally I might be willing to let
> the application be profilgate with power, so that web pages render a
> bit faster than they might otherwise --- but if I'm on an American
> Airlines flight which has retrofitted its power jacks to use an AC
> plug, and I only have a DC adaptor, and my laptop batteries are worn
> out and only have half their endurance as they used to, I might want
> to use a more stringent pm_qos than I might otherwise normally allow.

Right, but this comes back to the axes of control. They have to be
presented to the user in a simple but meaningful manner.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Sun, Aug 01, 2010 at 06:16:57PM -0400, Alan Stern wrote:
> On Sun, 1 Aug 2010, Paul E. McKenney wrote:
>
> > > I should have made a stronger point: "power-aware" is _not_ a good
> > > term for these applications. "power-enabled" would be better but
> > > still not ideal. Maybe "power-permitted"? The definition is that
> > > they are _permitted_ to do something (acquire suspend blockers), not
> > > that they actually _do_ something.
> >
> > How about "PM-driving applications", as Rafael suggested?
>
> Perhaps. But it's a little misleading, since what these applications
> are permitted to do is to _prevent_ the system from going to low power.
> So in a real sense they don't drive PM -- they block it. (Indeed,
> that's what inspired the name "suspend blocker".) Of course, the same
> objection applies to "power-permitted".

Good point, but for the moment I would like to keep the number of
classes of applications down to a dull roar, and so am proposing
one class for applications that either actively control device/system
power/sleep or prevent changes in same.

I am of course open to improvements in the "PM-driving applications"
name. ;-)

> > > I was agreeing with the requirement but disagreeing with the reason
> > > given for it. Even when buffers are large enough that the danger of
> > > overrunning them is infinitesimal, delays in input event delivery are
> > > still undesirable.
> > >
> > > Besides, the Android kernel doesn't vary its behavior based on whether
> > > the recipient is power-permitted or power-naive; it _always_ delivers
> > > input events in a timely fashion.
> >
> > True, the difference between the two classes of applications is in
> > whether or not the application is permitted to process the event.
> >
> > I added "and to minimize response latencies" to the requirement.
> > Does that capture it?
>
> Yes.

Very good!!!

> > > > But leaving that aside, I thought that Arve and Brian explicitly
> > > > stated this as a requirement on power-aware applications -- one of the
> > > > responsibilities that came with the power to block suspend.
> > >
> > > No. There are _no_ requirements on power-permitted (or power-aware if
> > > you prefer) applications, other than that the user decides to give it
> > > the appropriate permission.
> > >
> > > Internally, of course, Android may enforce this rule on their own
> > > software. But it has no force in regard to external applications.
> >
> > So should this be moved to a new "ANDROID POLICY" section or some such?
>
> Or DESIRED BEHAVIOR, or some such.

SUGGESTED USAGE?

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Sun, Aug 01, 2010 at 03:38:34PM -0700, David Brownell wrote:
> > > > I should have made a stronger point:
> > "power-aware" is _not_ a good
> > > > term for these applications.�
>
> Strongly disagree. The whole point is that they
> ARE VERY MUCH AWARE and interact with a power
> policy to achieve goals.
>
> Like refusing to power down active subsystems,
> or actively powering down inactive ones.
> Q.E.D. ... "aware".

My initial thoughts was along the same lines as yours, but after thinking
about it, the distinction between an application that controls its own
behavior ("power-aware application") and an application that controls the
system's behavior ("PM-driving application") seemed well worth its weight.

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Sun, Aug 01, 2010 at 06:16:33PM -0500, James Bottomley wrote:
> On Sat, 2010-07-31 at 22:48 -0700, Paul E. McKenney wrote:
> > On Sat, Jul 31, 2010 at 09:52:14PM -0700, Arjan van de Ven wrote:
> > > On Sat, 31 Jul 2010 10:58:42 -0700
> > > "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> wrote:
> > >
> > > > o "Power-aware application" are applications that are permitted
> > > > to acquire suspend blockers on Android. Verion 8 of the
> > > > suspend-blocker patch seems to use group permissions to
> > > > determine which applications are classified as power aware.
> > > >
> > > > More generally, power-aware applications seem to be those that
> > > > have permission to exert some control over the system's
> > > > power state.
> > >
> > > I don't like the term "Power aware application". An application is well
> > > behaved or it isn't. "aware" has nothing to do with it.
> >
> > Applications are often complex enough to be aware of some things, naive
> > about others, well behaved in some ways, and ill-behaved in others.
> > This has been the case for some decades now, so it should not come as
> > a surprise.
> >
> > I am of course open to suggestions for alternatives to the term "power
> > aware application", but most definitely not to obfuscating the difference
> > between power awareness (or whatever name one wishes to call it) and
> > the overall quality of the application, whatever "quality" might mean
> > in a given context.
>
> So the reason everyone's having trouble with this definition is that it
> actually conflates two separate axes of power management.
>
> There are good and bad applications in the power sense ... burns less vs
> burns more.
>
> And there are user mandated vs user optional processes ...
> necessary/wanted vs unnecessary/unwanted.
>
> What android actually does is reward well written applications because
> they "just work" and they don't have to be power aware at all ...
> they're usually event driven and split into the android
> provider/consumer model.
>
> Badly written applications that are not suspend block aware get shut
> down (by system suspend) when the screen turns off, so they're also
> power/suspend unaware.
>
> Applications that want to present the user with a choice in android are
> power/suspend aware because the only way they get to present the choice
> is via suspend blockers.
>
> The "power problem" always devolves to resolving a set of choices around
> a given set of control axes. The problem is that the set of control
> axes isn't unique and doesn't have a well agreed upon selection. This
> makes it hard to make definitive terminology because you have to pick
> the set of axes (implicitly or explicitly) before defining terms ...

That does seem to be about the size of it... :-/

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on
On Sun, Aug 01, 2010 at 04:40:26PM -0400, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 12:12:28PM -0700, Paul E. McKenney wrote:
> >
> > I understand that you would prefer that we group applications into
> > "good" and "bad" categories, but then again, I suspect that most of us
> > understood that before you posted this message. Given your significant
> > and well-appreciated contributions to power efficiency over the past
> > several years, I must confess to be quite disappointed that you failed
> > to do more than to simply restate your preference.
>
> Paul, I very much agree with what you stated later, with respect to
> doubting whether the whack-a-mole approach to application fixups is
> workable. Given how many applications screw up using fsync()
> correctly, to the extent that XFS, ext4, and btrfs all had to agree on
> a common hueristics to deal with the fact that application programmers
> are aggressively ignorant, and outnumber the file system developers, I
> too doubt the general strategy of relying only on application
> programmers to do the right thing. That's not to say that we
> shouldn't give up on trying to influence application programmers ---
> but relying on that as the only strategy seems to depart from the path
> of wisdom.

Unless someone can reliably automate whacking the moles, history is not
on the side of the mole-whackers. I won't say that such automation
is impossible, but only because of all the "impossible" things in my
lifetime that have turned out to be possible.

And I agree that multiple approaches are likely to be needed here.

> There is however a much bigger point, which is that it's unfortunately
> black and white to talk about applications being "good" and "bad". In
> fact, it's a continuing point of concern I have with the whole qos
> approach to power management. In fact, power is often something that
> needs to trade off against performance. For example, an application
> could aggressively prefetch e-mail messages or web pages that a user
> _might_ view --- or it could aggressively pre-resolve DNS queries,
> etc, which might make perfect sense when the device is hooked up to AC
> mains, but which I might not want to do on when I only have 800mWh
> worth of battery --- however, if I'm using a laptop with 94,000mWh,
> maybe I'd be happy if the application was a bit more profligate.
>
> So for Arjan to claim that all applications will be held to the same
> standard, whether they are hooked up to the AC mains, or are limited
> to 800mWh of battery, or 94,000 mWh worth of power, is vastly
> oversimplifying the problem. Of *course* if I'm writing an
> application that will be running in a cloud data center, I'm going to
> care about power. But I may have different tradeoffs about what might
> considered acceptible when considering the qualify of user experience
> I'm delivering to the end-user when I'm connected to AC mains, versus
> a cell phone battery, versus a 6-cell laptop battery.

And depending on how badly you need the application to run. "Find me
the nearest source of AC power!" "Sorry, can't do that because that app
is too poorly behaved to run when the battery is nearly exhausted." ;-)

Arjan did suggest taking user preferences into account, but we will see.

> This brings me back to a major problem I have with the pm_qos approach
> to power management. It assumes that applications know best, and that
> they should be free to tell pm_qos subsystem whether they need 0ms
> latency for wireless. Right now, I can't even query the pm_qos
> subsystem to see which application is responsible for keeping the
> wireless on 100% of the time! And even if I could find out, maybe
> some power management framework should be allowed to give a override
> to the application's wishes. OK, maybe the Opera web browser is
> requesting the very best wireless QOS because it wants to beat Chrome
> on some silly potato benchmark --- well, it's ***stupid*** to say that
> my power management should be a one-size-fits all because applications
> should be always as power efficient as possible whether they are
> connected to AC mains or I have a 800mWh cell phone battery. Worse
> yet, it's stupid to say that the application should have the last
> word. Darn it, *I* own the mobile device, and I (or my proxy, which
> might be the Android OS, or some power manage daemon) should be able
> to say, "I don't care what the application claimed it wanted for power
> QOS --- it's not getting more than 100ms wireless latency, and that's
> final."
>
> And note that this is something that might even change over time, or
> depending on circumstances. Maybe normally I might be willing to let
> the application be profilgate with power, so that web pages render a
> bit faster than they might otherwise --- but if I'm on an American
> Airlines flight which has retrofitted its power jacks to use an AC
> plug, and I only have a DC adaptor, and my laptop batteries are worn
> out and only have half their endurance as they used to, I might want
> to use a more stringent pm_qos than I might otherwise normally allow.

Agreed!

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