Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Arjan van de Ven on 1 Aug 2010 02:10
On Sat, 31 Jul 2010 22:48:16 -0700
"Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> 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 do not like the term "aware". At all.
It implies "awareness", and implies it does things based on the power
circumstances.

It's about *behaving well*. (not polling, not having activity when
there is nothing to do etc etc). Not about being aware that power
matters.

I can write a very shitty application that polls all the time and
otherwise keeps the CPU and system busy, but it'll be aware that power
matters.. it just doesn't behave accordingly.



>
> The choice between power-aware and power-naive will depend on who is
> available to do the programming and how valuable power-awareness is
> for the application in question. Given that people who program
> PC-class applications are much more common than are people who
> program with energy efficiency in mind, the power-naive choice will
> be attractive in many cases.

I'm not sure I buy that.
4 years ago.. yes.
Today.. with PowerTOP and co out there for a long time?
I don't believe that anymore. Most of our open source PC apps are
actually very well behaving in the power sense.
Yes an occasional bug slips in, and then gets fixed quickly.
(speaking as someone who does this sort of work for a Linux
distribution... yes bugs happen on a whole distro level, but they're
also not all that common, and get fixed quickly)




--
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: Mikael Abrahamsson on 1 Aug 2010 02:30
On Sat, 31 Jul 2010, Paul E. McKenney wrote:

> available to do the programming and how valuable power-awareness is for
> the application in question. Given that people who program PC-class
> applications are much more common than are people who program with
> energy efficiency in mind, the power-naive choice will be attractive in
> many cases.

I own a Nokia N900. Some applications are ported straight from regular
Linux and they're definitely power-naive, as they have little or no
optimization for mobile. I agree that this is not "sloppy" or "bad", it's
just that mobile (low power) wasn't the intended target of the application
when it was written, and this commonly shows.

Just like some people will burn CPU cycles by writing their application in
a high-level language because it requires fewer man-hours and that you get
thousands of cpu-hours for the cost of a man-hour programming the thing
(often by externalising the true cost of power which makes power even less
of a problem), not caring much about power is rational behaviour when
creating an application for pc.

Just look at flash ads, they consume huge amounts of power and they
commonly never stop. I imagine that the power used by PCs around the world
displaying web pages with advertising with the monitor in power-save mode
(powered down) can be counted in gigawatts. When I need my battery to last
on my laptop I make sure I don't have any unneccessary tabs enabled
because it seriously affects my battery time. I think laptop users would
benefit from more power optimized applications as well, so if the OS could
do the same for laptop/desktop use as well (spending less time on programs
updating display when the display is off), I think there are real world
benefits for every desktop/laptop/mobile user.

If nothing else, it's environmentally friendly.

--
Mikael Abrahamsson email: swmike(a)swm.pp.se
--
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: Mikael Abrahamsson on 1 Aug 2010 02:50
On Sun, 1 Aug 2010, Mikael Abrahamsson wrote:

> it's just that mobile (low power) wasn't the intended target of the
> application when it was written, and this commonly shows.

I have another aspect I just thought about. I work for a telephony
company. We provide Internet connectivity throught various means, DSL,
Ethernet to the Home, mobile etc.

For ETTH and DSL, network usage is pretty straight forward, you send
packets, they get delivered pretty quickly with low marginal cost per
packet. For mobile, this is not quite so simple. Mobile networks are
designed for terminal/UE (user equipment) to use low power, so they go
down in low power state after a while. Let's take the case of 3G/HSPA:

After a short while (second) of idleness (no packets being sent), the
mobile network negotiates away the high speed resources (the one that
enables multimegabit/s transfers) and tries to give it to someone else.
After approximately 30 seconds, the terminal goes to "idle", meaning it
has no network resources at all. Next time it wants to send something (or
the network wants to deliver something to it), network resources need to
be negotiated again. This can take 1-2 seconds and uses battery power of
course. It also consumes resources in the operator network (because
mobility control units need to talk to base stations, tunnels need to be
re-negotiated etc).

Anyhow, my point is that not only is there a benefit in having multiple
applications wake up at the same time for power reasons within the device,
there is also a point in having coordination of their network access. If a
device is running 3 IM programs at the same time, it'd be beneficial if
they were coordinated in their communication with their Internet servers.
Same goes for the "check for new email" application. If they all were
optimized to only wake up the network connectivity once every 180 seconds
instead of doing it when the individual application felt like it, power
and other resources would be saved by all involved parties.

--
Mikael Abrahamsson email: swmike(a)swm.pp.se
--
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 1 Aug 2010 11:50
On Saturday, July 31, 2010, Alan Stern wrote:
> On Sat, 31 Jul 2010, Paul E. McKenney wrote:
>
> > Rushing in where angels fear to tread...
> >
> > I had been quite happily ignoring the suspend-blockers controversy.
> > However, now that I have signed up for the Linaro project that involves
> > embedded battery-powered devices, I find that ignorance is no longer
> > bliss. I have therefore reviewed much of the suspend-blocker/wakelock
> > material, but have not yet seen a clear exposition of the requirements
> > that suspend blockers are supposed to meet. This email is a attempt
> > to present the requirements, based on my interpretation of the LKML
> > discussions.
> >
> > Please note that I am not proposing a solution that meets these
> > requirements, nor am I attempting to judge the various proposed solutions.
> > In fact, I am not even trying to judge whether the requirements are
> > optimal, or even whether or not they make sense at all. My only goal
> > at the moment is to improve my understanding of what the Android folks'
> > requirements are. That said, I do include example mechanisms as needed to
> > clarify the meaning of the requirements. This should not be interpreted
> > as a preference for any given example mechanism.
> >
> > But first I am going to look at nomenclature, as it appears to me that
> > at least some of the flamage was due to conflicting definitions. Following
> > that, the requirements, nice-to-haves, apparent non-requirements,
> > an example power-optimized applications, and finally a brief look
> > at other applications.
> >
> > Donning the asbestos suit, the one with the tungsten pinstripes...
> >
> > Thanx, Paul
>
> At the risk of sticking my neck out, I think a few of your statements
> don't fully capture the important ideas.
>
> > ------------------------------------------------------------------------
> >
> > DEFINITIONS
> >
> > o "Ill-behaved application" AKA "untrusted application" AKA
> > "crappy application". The Android guys seem to be thinking in
> > terms of applications that are well-designed and well-implemented
> > in general, but which do not take power consumption or battery
> > life into account. Examples include applications designed for
> > AC-powered PCs. Many other people seemed to instead be thinking
> > in terms of an ill-conceived or useless application, perhaps
> > exemplified by "bouncing cows".
> >
> > Assuming I have correctly guessed what the Android guys were
> > thinking of, perhaps "power-naive applications" would be a
> > better description, which I will use until someone convinces
> > me otherwise.

I'd slightly prefer these to be called "power-oblvious applications", to
reflect the fact that their authors might not take power management into
consideration in any form.

> > 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.
>
> Notice that these definitions allow a program to be both power-naive
> and power-aware. In addition, "power-awareness" isn't an inherent
> property of the application itself, since users are allowed to decide
> which programs may exert control over the system's power state. The
> same application could be power-aware on one system and non-power-aware
> on another.

Also, there is another type of "power-awareness", related to the ability to
react to power management events signaled, for example, by pm-utils using
dbus protocol (NetworkManager is one such application). However, the
applications having that ability don't really participate in making a decision
to change the state of the system, while the applications using wakelocks do.

In the wakelocks (or suspend blockers, whatever you prefer to call them) world
no single entity is powerful enough to make the system go into a sleep state,
but some applications and device drivers collectively can make that happen.
The applications using wakelocks not only are aware of system power
management, but also are components of a "collective power manager", so
perhaps it's better to call them "PM-driving applications" or something like
this.

> > o Oddly enough, "power-optimized applications" were not discussed.
> > See "POWER-OPTIMIZED APPLICATIONS" below for a brief introduction.
> > The short version is that power-optimized applications are those
> > power-aware applications that have been aggressively tuned to
> > reduce power consumption.
>
> This would be essentially the same as power-aware && !power_naive,
> right?

Not really, IMO. !power_naive means "doesn't use wakelocks" in this context,
while "power-optimized" would mean something like "not only uses wakelocks,
but also tries to reduce energy consumption by as much as possible".

> > REQUIREMENTS
> >
> > o Reduce the system's power consumption in order to (1) extend
> > battery life and (2) preserve state until AC power can be obtained.
>
> External power, not necessarily AC power (a very minor point).
>
> > o It is necessary to be able to use power-naive applications.
> > Many of these applications were designed for use in PC platforms
> > where power consumption has historically not been of great
> > concern, due to either (1) the availability of AC power or (2)
> > relatively undemanding laptop battery-lifetime expectations. The
> > system must be capable of running these power-naive applications
> > without requiring that these applications be modified, and must
> > be capable of reasonable power efficiency even when power-naive
> > applications are available.
> >
> > o If the display is powered off, there is no need to run any
> > application whose only effect is to update the display.
>
> On Android this goes somewhat farther. IIUC, they want hardly anything
> to run while the display is powered off. (But my understanding could
> be wrong.)

Not really. Quite a lot of things happen on these systems while the display
is off (let alone the periodic battery monitoring on Nexus One :-)). They
can send things over the network and do similar stuff in that state.

I think the opposite is true, ie. the display is aggressively turned off
whenever it appears not to be used, because it draws a lot of power.

> For computers in general, of course, this statement is correct. The
> same is true for any output-only device. For example, if the audio
> speakers are powered off, there is no need to run any application whose
> only effect is to play sounds through the speakers.

Agreed.

> > Although one could simply block such an application when it next
> > tries to access the display, it appears that it is highly
> > desirable that the application also be prevented from
> > consuming power computing anything that will not be displayed.
> > Furthermore, whatever mechanism is used must operate on
> > power-naive applications that do not use blocking system calls.
> >
> > o In order to avoid overrunning hardware and/or kernel buffers,
> > input events must be delivered to the corresponding application
> > in a timely fashion. The application might or might not be
> > required to actually process the events in a timely fashion,
> > depending on the specific application.
>
> This goes well beyond overrunning buffers! Events must be delivered in
> a timely fashion so that the system isn't perceived to be inoperative.

That's correct, although it doesn't seem to apply to any kind of input
events. For example, on Nexus One the touchscreen doesn't generate wakeup
events (ie. events that wake the system up from a sleep states), so I'm not
sure to what extent they are supposed to block (automatic) suspends.

> > In particular, if user input that would prevent the system
> > from entering a low-power state is received while the system is
> > transitioning into a low-power state, the system must transition
> > back out of the low-power state so that it can hand the user
> > input off to the corresponding application.

Side note. I'd like to avoid confusing device states with system-as-a-whole
states, so I always prefer to refer to the system-as-a-whole-low-power states
as "system sleep states", while term "low-power state" is reserved for
individual devices.

Also in some cases (ACPI mostly) a "system sleep state" is more than a
"system low-power state", because you can put the system into a low-power
state by putting a number of devices into low-power states, which is not
sufficient to put the system into a sleep state (the platform has to be
programmed in a special way to carry out that operation). Now, wakelocks
are about "system sleep states", not about "system low-power states" in
general.

> > o If a power-aware application receives user input, then that
> > application must be given the opportunity to process that
> > input.
>
> A better way to put this is: The API must provide a means for
> power-aware applications receiving user input to keep themselves
> running until they have been able to process the input.
>
> This is probably also true for power-aware applications having other
> needs (e.g., non-input-driven computation). In general, power-aware
> applications must have a mechanism to prevent themselves from being
> stopped for power-related reasons.

Agreed.

> > o A power-aware application must be able to efficiently communicate
> > its needs to the system, so that such communication can be
> > performed on hot code paths. Communication via open() and
> > close() is considered too slow, but communication via ioctl()
> > is acceptable.
> >
> > o Power-naive applications must be prohibited from controlling
> > the system power state. One acceptable approach is through
> > use of group permissions on a special power-control device.
>
> You mean non-power-aware applications, not power-naive applications.
> But then the statement is redundant; it follows directly from the
> definition of "power-aware".

Agreed.

> > o Statistics of the power-control actions taken by power-aware
> > applications must be provided, and must be keyed off of program
> > name.
> >
> > o Power-aware applications can make use of power-naive infrastructure.
> > This means that a power-aware application must have some way,
> > whether explicit or implicit, to ensure that any power-naive
> > infrastructure is permitted to run when a power-aware application
> > needs it to run.
> >
> > o When a power-aware application is preventing the system from
> > shutting down, and is also waiting on a power-naive application,
> > the power-aware application must set a timeout to handle
> > the possibility that the power-naive application might halt
> > or otherwise fail. (Such timeouts are also used to limit the
> > number of kernel modifications required.)
>
> No, this is not a requirement. A power-optimized application would do
> this, of course, by definition. But a power-aware application doesn't
> have to.

Agreed.

> > o If no power-aware or power-optimized application are indicating
> > a need for the system to remain operating, the system is permitted
> > (even encouraged!) to suspend all execution, even if power-naive
> > applications are runnable. (This requirement did appear to be
> > somewhat controversial.)
>
> The controversy was not over the basic point but rather over the
> detailed meaning of "runnable". A technical matter, related to the
> implementation of the scheduler.

Well, I _think_ it was about the basic point too, since "all execution" means
periodic timers in particular and involves shutting down clock sources (except
for the RTC).

Arguably, suspending "all execution" is not necessary to achieve a satisfactory
level of energy saving, at least on a number of systems.

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: Paul E. McKenney on 1 Aug 2010 15:20
On Sat, Jul 31, 2010 at 11:01:01PM -0700, Arjan van de Ven wrote:
> On Sat, 31 Jul 2010 22:48:16 -0700
> "Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com> 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 do not like the term "aware". At all.
> It implies "awareness", and implies it does things based on the power
> circumstances.
>
> It's about *behaving well*. (not polling, not having activity when
> there is nothing to do etc etc). Not about being aware that power
> matters.
>
> I can write a very shitty application that polls all the time and
> otherwise keeps the CPU and system busy, but it'll be aware that power
> matters.. it just doesn't behave accordingly.

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.

However, your words below are much more to the point, so I will respond
to them.

> > The choice between power-aware and power-naive will depend on who is
> > available to do the programming and how valuable power-awareness is
> > for the application in question. Given that people who program
> > PC-class applications are much more common than are people who
> > program with energy efficiency in mind, the power-naive choice will
> > be attractive in many cases.
>
> I'm not sure I buy that.
> 4 years ago.. yes.
> Today.. with PowerTOP and co out there for a long time?
> I don't believe that anymore. Most of our open source PC apps are
> actually very well behaving in the power sense.
> Yes an occasional bug slips in, and then gets fixed quickly.
> (speaking as someone who does this sort of work for a Linux
> distribution... yes bugs happen on a whole distro level, but they're
> also not all that common, and get fixed quickly)

I agree that much progress has been made over the past four years.
My laptop's battery life has increased substantially, with roughly half
of the increase due to software changes. Taken over all the laptops and
PCs out there, this indeed adds up to substantial and valuable savings.

So, yes, you have done quite well.

However, your reliance on application-by-application fixes, while good
up to a point, is worrisome longer term. The reason for my concern is
that computing history has not been kind to those who fail to vigorously
automate. The Android guys have offered up one way of automating power
efficiency. There might be better ways, but their approach does at
the very least deserve a fair hearing -- and no one who read the recent
LKML discussion of their approach could possibly mistake it for anything
resembling a fair hearing.

And yes, I do understand and appreciate your contributions in the form of
things like timer aggregation, which does automate the otherwise-tricky
task of coordinating power usage across unrelated applications, at
least in some important cases. But power efficiency will likely require
multiple approaches, especially if the Linux stack is to approach the
power efficiencies provided by dedicated devices.

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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....