From: Arjan van de Ven on
On Sun, 1 Aug 2010 16:40:26 -0400

>
> There is however a much bigger point, which is that it's unfortunately
> black and white to talk about applications being "good" and "bad".

I'll agree with this.

this is extremely situational.. not only where things run, but also,
which part of the application you're talking about. If your application
has 3 features (a $0.99 app store app) it's not too burdensome to make
all 3 features work well for "power on a phone".
If your app has 5000 features... what do you do when 4500 are behaving
well, and the other 500 are somewhat obscure?


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

this is a very tricky area; because prefetching may well be good for
power as well.... but "it depends"...

getting DNS ahead of time when you're doing other network stuff anyway?
probably a good idea for power, at least when done in moderation. It
might save a modem wakeup two seconds down the road.

excessively prefetching DNS all the time? probably not a good idea for
power.



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

yes if we allowed apps to do this, we absolutely need
accountability/diagnostics into it.

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

QOS also should be a request.. and depend on who's asking.
If you run as root with realtime privileges, the kernel should probably
just give you what you asked for.
If you run as UID 500.... there needs to be either a static rlimit kind
of thing, or an intelligent dynamic "clip" to what you ask versus what
the system administrator (or his delegate in the form of some policy
daemon) wants you to do.



--
Arjan van de Ven Intel 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-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: Rafael J. Wysocki on
On Sunday, August 01, 2010, 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.
>
> 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.
>
> 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.

I agree with that.

Generally speaking, you can divide applications into the ones that will be
allowed to influence ths system's behavior with respect to power management
and the others that won't be allowed to do it. The latter may be forcibly
"frozen" (this way or another) when the "trused" ones collectively decide it's
a good idea to enter a deeper "energy saving" state. However, it is not a
given that specific applications will always be in the same group. They may
be "trusted" on some systems and they may not be "trusted" on some other
system, depending on the configuration etc. That even may change over time
on the same system.

Thanks,
Rafael
--
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: David Brownell on

> be "trusted" on some systems and they may not be "trusted"
> on some other
> system, depending on the configuration etc.

Yes, let's reserve "trusted" for security contexts.
One might view agressively bad power management as
a security threat, of course: when the machine
becomes unavailable because its battery dies, that
can be viewed as a security attack, since keeping the machine available is the primary security goal.

Distinguish bugs from broken-by-design, too.

- Dave


--
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: Arjan van de Ven on
On Mon, 2 Aug 2010 01:02:24 +0200
"Rafael J. Wysocki" <rjw(a)sisk.pl> wrote:
>
> Generally speaking, you can divide applications into the ones that
> will be allowed to influence ths system's behavior with respect to
> power management and the others that won't be allowed to do it. The
> latter may be forcibly "frozen" (this way or another) when the
> "trused" ones collectively decide it's a good idea to enter a deeper
> "energy saving" state. However, it is not a given that specific
> applications will always be in the same group. They may be "trusted"
> on some systems and they may not be "trusted" on some other system,
> depending on the configuration etc. That even may change over time
> on the same system.
>

it might even be a sliding scale; the voting rights don't have to be
"0" and "1", but could also be "0.2" and such....
--
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: James Bottomley on
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 ...

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/