Prev: [PATCH 6/7] usb: iowarrior: fix misuse of return value of copy_to_user()
Next: Get Back To Me Immediately....
From: Paul E. McKenney on 31 Jul 2010 14:00
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

------------------------------------------------------------------------

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.

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.

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.


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.

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.

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.

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.

o If a power-aware application receives user input, then that
application must be given the opportunity to process that
input.

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.

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

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

o Transition to low-power state must be efficient. In particular,
methods based on repeated attempts to suspend are considered to
be too inefficient to be useful.

o Individual peripherals and CPUs must still use standard
power-conservation measures, for example, transitioning CPUs into
low-power states on idle and powering down peripheral devices
and hardware accelerators that have not been recently used.

o The API that controls the system power state must be
accessible both from Android's Java replacement, from
userland C code, and from kernel C code (both process
level and irq code, but not NMI handlers).

o Any initialization of the API that controls the system power
state must be unconditional, so as to be free from failure.
(I don't currently understand how this relates, probably due to
my current insufficient understanding of the proposed patch set.)

o The API that controls the system power state must operate
correctly on SMP systems of modest size. (My guess is that
"modest" means up to four CPUs, maybe up to eight CPUs.)

o Any QoS-based solution must take display and user-input
state into account. In other words, the QoS must be
expressed as a function of the display and the user-input
states.

o Transitioning to extremely low power states requires saving
and restoring DRAM and/or cache SRAM state, which in itself
consumes significant energy. The power savings must therefore
be balanced against the energy consumed in the state
transitions.

o The current Android userspace API must be supported in order
to support existing device software.


NICE-TO-HAVES

o It would be nice to be able to identify power-naive applications
that never were depended on by power-aware applications. This
particular class of power-naive applications could be shut down
when the screen blanks even if some power-aware application
was preventing the system from powering down. (I am guessing
at this one based on the momentary excitement that cgroup
freezing raised in the Android folks. Of course, this approach
requires a reliable way to identify such applications.)


APPARENT NON-REQUIREMENTS

o Transitioning to low-power states need not be highly scalable,
as evidenced by the global locks. (If you believe that this
will in fact be required, please provide a use case. But please
understand that I do know something about scalability trends,
but also about uses for transistors beyond more cores.)


POWER-OPTIMIZED APPLICATIONS

A typical power-optimized application manually controls the power state
of many separately controlled hardware subsystems to minimize power
consumption. Such optimization normally requires an understanding
of the hardware and of the full system's workload: strangely enough,
concurrently running two separately power-optimized applications often
does -not- result in a power-optimized system. Such optimization also
requires knowledge of what the application will be doing in the future,
so that needed hardware subsystems can be proactively powered up just
when the application will need them. This is especially important when
powering down cache SRAMS or banks of main memory, because such components
take significant time (and consume significant energy) when preparing them
to be powered off and when restoring their state after powering them on.

Consider an MP3 player as an example. Such a player will periodically
read MP3-encoded data from flash memory, decode it (possibly using
hardware acceleration), and place the resulting audio data into main
memory. Different systems have different ways of getting the data from
main memory to the audio output device, but let's assume that the audio
output device consumes data at a predictable rate such that the software
can use timers to schedule refilling of the device's output buffer.
The timer duration will of course need to allow for the time required to
power up the CPU and L2 cache. The timer can be allowed to happen too
soon, albeit with a battery-lifetime penalty, but cannot be permitted
to happen too late, as this will cause "skips" in the playback.

If MP3 playback is the only application running in the system, things
are quite easy. We calculate when the audio output device will empty
its buffer, allow a few milliseconds to power up the needed hardware,
and set a timer accordingly. Because modern audio output devices have
buffers that can handle roughly a second's worth of output, it is well
worthwhile to spend the few milliseconds required to flush the cache
SRAMS in order to put the system into an extremely low power state over
the several hundred milliseconds of playback.

Now suppose that this device is also recording audio -- perhaps the
device is being used to monitor an area for noise pollution, and the
user is also using the device to play music via earphones. The audio
input process will be the inverse of the audio output process: the
microphone data will fill a data buffer, which must be collected into
DRAM, then encoded (perhaps again via MP3) and stored into flash.
It would be easy to create an optimal application for audio input,
but running this optimal audio input program concurrently with the
optimal audio playback program would not necessarily result in
a power-optimized combination. This lack of optimality is due to
the fact that the input and output programs would each burn power
separately powering down and up. In contrast, an optimal solution
would align the input and output programs' timers so that a single
power-down/power-up event would cover both programs' processing.
This would trade off optimal processing of each (for example,
by draining the input buffer before it was full) in order to attain
global optimality (by sharing power-down/power-up overhead).

There are a number of ways to acheive this:

1. Making the kernel group timers that occur at roughly the same
time, as has been discussed on this list many times. This can
work in many cases, but can be problematic in the audio example,
due to the presence of hard deadlines.

2. Write the programs to be aware of each other, so that each
adjusts its behavior when the other is present. This seems
to be current practice in the battery-powered embedded arena,
but is quite complex, sensitive to both hardware configuration
and software behavior, and requires that all combinations of
programs be anticipated by the designer -- which can be a serious
disadvantage given today's app stores.

3. Use new features such as range timers, so that each program
can indicate both its preference and the degree of flexibility
that it can tolerate. This also works in some cases, but as
far as I know, current proposals do not allow the kernel to take
power-consumption penalties into account.

4. Use of hardware facilities that allow DMA to be scheduled across
time. This would allow the CPU to be turned on only for
decode/encode operations. I am under the impression that this
sort of time-based DMA hardware does exist in the embedded space
and that it is actually used for this purpose.

5. Your favorite solution here.

Whatever solution is chosen, the key point to keep in mind is that
running power-optimized applications in combination does -not- result
in optimal system behavior.


OTHER EXAMPLE APPLICATIONS

GPS application that silently displays position.

There is no point in this application consuming CPU cycles
or in powering up the GPS hardware unless the display is
active. Such an application could be handled by the Android
suspend-blocker proposal. Of course, such an application could
also periodically poll the display, shutting itself down if the
display is inactive. In this case, it would also need to have
some way to be reactivated when the display comes back on.

GPS application that alerts the user when a given location is reached.

This application should presumably run even when the display
is powered down due to input timeout. The question of whether
or not it should continue running when the device is powered
off is an interesting one that would be likely to spark much
spirited discussion. Regardless of the answer to this question,
the GPS application would hopefully run very intermittently,
adjusting the delay interval based on the device's velocity and
distance from the location in question.

I don't know enough about GPS hardware to say under what
circumstances the GPS hardware itself should be powered off.
However, my experience indicates that it takes significant
time for the GPS hardware to get a position fix after being
powered on, so presumably this decision would also be based
on device velocity and distance from the location in question.

Assuming that the application can run only intermittently,
suspend blockers would work reasonably well for this use case.
If the application needed to run continuously, battery life
would be quite short regardless of the approach used.

MP3 playback.

This requires a power-aware (and preferably a power-optimized)
application. Because the CPU need only run intermittently,
suspend blockers can handle this use case. Presumably switching
the device off would halt playback.

Bouncing cows.

This can work with a power-naive application that is shut down
whenever the display is powered off or the device is switched off,
similar to the GPS application that silently displays position.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 31 Jul 2010 16:30
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.
>
> 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.

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

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

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.

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

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

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

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

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

> o Transition to low-power state must be efficient. In particular,
> methods based on repeated attempts to suspend are considered to
> be too inefficient to be useful.
>
> o Individual peripherals and CPUs must still use standard
> power-conservation measures, for example, transitioning CPUs into
> low-power states on idle and powering down peripheral devices
> and hardware accelerators that have not been recently used.
>
> o The API that controls the system power state must be
> accessible both from Android's Java replacement, from
> userland C code, and from kernel C code (both process
> level and irq code, but not NMI handlers).
>
> o Any initialization of the API that controls the system power
> state must be unconditional, so as to be free from failure.
> (I don't currently understand how this relates, probably due to
> my current insufficient understanding of the proposed patch set.)

I suspect this is not a critical requirement, more like a NICE-TO-HAVE.

> o The API that controls the system power state must operate
> correctly on SMP systems of modest size. (My guess is that
> "modest" means up to four CPUs, maybe up to eight CPUs.)

For present-day phones this obviously doesn't matter, but if the API is
going to be used on more general systems then it does.

> o Any QoS-based solution must take display and user-input
> state into account. In other words, the QoS must be
> expressed as a function of the display and the user-input
> states.
>
> o Transitioning to extremely low power states requires saving
> and restoring DRAM and/or cache SRAM state, which in itself
> consumes significant energy. The power savings must therefore
> be balanced against the energy consumed in the state
> transitions.
>
> o The current Android userspace API must be supported in order
> to support existing device software.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 1 Aug 2010 00:40
On Sat, Jul 31, 2010 at 04:19:48PM -0400, 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.

Fair enough! ;-)

And thank you for looking this over!!!

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

Agreed.

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

It certainly seems to me that most power-optimized applications would
need to be classified as power-aware to work properly. But there could
easily be power-aware applications that aren't heavily power-optimized,
for example, such an application might make use of the CPU for operations
that could be handled by a power-efficient hardware accelerator.
Perhaps power-aware is to power-optimized as SMP-safe is to perfectly
optimized for SMP scalability and performance.

Though it seems that heavy power-efficiency optimizations might come
at the expense of portability in some cases.

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

A good one, though.

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

I agree that this requirement is but one piece of the Android puzzle.

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

Good point -- I didn't find any example of this in the email threads,
but it does seem plausible.

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

Agreed for power-aware applications. For power-naive applications,
the last event delivered can be buffered by the application with no
response if I understand correctly. If there is a subsequent event
for that same application, then the prior event can be processed.

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

Good point! Would it also make sense to say "events" in general rather
than "input" in particular?

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

I thought I covered this in the next requirement. Did I miss some aspect?

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

I see your point, but I don't feel comfortable deleting this requirement.
My rationale is that the definition needs some enforcement mechanism,
and this requirement is calling out the need for such a mechanism.

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

I am not sure we agree on the definition of "power-optimized application".
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.

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

OK, what would you suggest for the wording of this requirement?

> > o Transition to low-power state must be efficient. In particular,
> > methods based on repeated attempts to suspend are considered to
> > be too inefficient to be useful.
> >
> > o Individual peripherals and CPUs must still use standard
> > power-conservation measures, for example, transitioning CPUs into
> > low-power states on idle and powering down peripheral devices
> > and hardware accelerators that have not been recently used.
> >
> > o The API that controls the system power state must be
> > accessible both from Android's Java replacement, from
> > userland C code, and from kernel C code (both process
> > level and irq code, but not NMI handlers).
> >
> > o Any initialization of the API that controls the system power
> > state must be unconditional, so as to be free from failure.
> > (I don't currently understand how this relates, probably due to
> > my current insufficient understanding of the proposed patch set.)
>
> I suspect this is not a critical requirement, more like a NICE-TO-HAVE.

You could well be correct, though the Android guys stated it pretty
strongly. Seems like the usual memory and mass-storage shortages would
be hard to handle with an unconditional API, though the usual solution
seems to be to make sure that there is enough for normal operation.

> > o The API that controls the system power state must operate
> > correctly on SMP systems of modest size. (My guess is that
> > "modest" means up to four CPUs, maybe up to eight CPUs.)
>
> For present-day phones this obviously doesn't matter, but if the API is
> going to be used on more general systems then it does.

Indeed, at least if the API is not to be stubbed out for all
large systems. Though it might be possible to make a more-scalable
implementation of this API, especially if larger systems were more
forgiving of time delays in noting any transitions.

> > o Any QoS-based solution must take display and user-input
> > state into account. In other words, the QoS must be
> > expressed as a function of the display and the user-input
> > states.
> >
> > o Transitioning to extremely low power states requires saving
> > and restoring DRAM and/or cache SRAM state, which in itself
> > consumes significant energy. The power savings must therefore
> > be balanced against the energy consumed in the state
> > transitions.
> >
> > o The current Android userspace API must be supported in order
> > to support existing device software.

Thank you again for looking this over!

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: Arjan van de Ven on 1 Aug 2010 01:00
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.


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

AC power is not relevant in discussions around power: Applications MUST
behave well, AC or DC both. Just ask any data center operator on how
much they run on DC and if he cares about power consumption.
Conversely, most mobile usages (both phone, tablet or netbook) are "DC
only"....






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

I don't buy this argument as is.

I do buy that there are many sloppy applications; mostly written quickly
for <appstore of the month>. But most if not all of these are written
for the device in question (at least that is true for Apple and Android)



--
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 01:50
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.

> > 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.
>
> AC power is not relevant in discussions around power: Applications MUST
> behave well, AC or DC both. Just ask any data center operator on how
> much they run on DC and if he cares about power consumption.
> Conversely, most mobile usages (both phone, tablet or netbook) are "DC
> only"....

Alan Stern suggested "external power" in place of "AC", which makes sense
to me. His suggestion does have the virtue of rendering irrelevant the
difference between an AC adapter and a DC adapter for use in automobiles.

And in my experience, people working with mobile devices care -much- more
about energy efficiency than do data-center operators.

> > 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.
>
> I don't buy this argument as is.
>
> I do buy that there are many sloppy applications; mostly written quickly
> for <appstore of the month>. But most if not all of these are written
> for the device in question (at least that is true for Apple and Android)

Making an application power-aware or power-naive is a choice, similar to
the choice between making an application SMP-aware or single-threaded.
This sort of choice is completely orthogonal to ill-behavior, sloppiness,
or whatever the pejorative of the day might be.

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.

Or do you have some other interpretation of what the Android guys are
looking for?

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