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.
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
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
On Sat, 31 Jul 2010 10:58:42 -0700
"Paul E. McKenney" <[email protected]> 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)
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" <[email protected]> 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
On Sat, 31 Jul 2010 22:48:16 -0700
"Paul E. McKenney" <[email protected]> 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" <[email protected]> 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
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: [email protected]
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: [email protected]
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
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" <[email protected]> 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" <[email protected]> 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
On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote:
> 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.
Good points in both this and your earlier post!!!
> 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.
This is a good point. Within some limits, the timer-aggregation
changes that have gone into Linux can handle this, but I am not sure
whether or not 180 seconds is within the reasonable boundaries for
timer jitter.
Of course, the timers might be synchronized upon wakeup after a
sufficiently long suspension, but they would not necessarily stay
synchronized without the help of some other mechanism, such as the
afore-mentioned timer-aggregation changes.
Thanx, Paul
> > > 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.
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.
> > > 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.
Arjan's point here is well taken. Even systems that always run on
external power have motivation for conserving energy (e.g., they may
be required by government regulation to do so).
> > > 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.
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.
> > > 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?
Sure.
> > > 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.
Then state it immediately after the definition as an implication of
the definition, not as a separate system requirement.
> > > 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.
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.
> > > 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?
Change the last phrase to "regardless of the state of power-naive
applications".
Alan Stern
On Sat, 31 Jul 2010, Paul E. McKenney 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.
This is a false dichotomy. The two of you have fallen into a logical
trap. I forget the word used to describe an argument based on a
fundamental misunderstanding, but it applies here.
The term "power-aware" has _nothing_ to do with how well behaved an
application is, or its quality (in any sense). Go back and re-read the
definition; you'll see what I mean.
Alan Stern
On Sun, Aug 01, 2010 at 05:41:30PM +0200, Rafael J. Wysocki wrote:
> 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.
I am fine with "power-oblivious applications".
> > > 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.
Perhaps this group is best named "power-aware applications"?
> 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.
Right, any PM-driving application can -prevent- the system from entering
a deep sleep state, but no single application can force this -- aside
from using the traditional non-opportunistic suspend facility, that is.
> > > 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".
I agree with this. A power-optimized application is something that
goes to lengths to minimize its power consumption, regardless of whether
something like wakelocks is in the picture.
> > > 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.
Fair enough. It appears to me that Android won't suspend if the display
is on, but I could easily be confused here.
> > 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.
Good point, I forgot that not all events do wakeups. I updated accordingly.
> > > 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.
Good point, noted.
> > > 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.
OK, but I still believe that an enforcement mechanism is required.
> > > 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.
Again, this requirement was explicitly called out by the Android folks.
> > > 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.
Indeed, some embedded systems are capable of doing quite a lot even when
almost everything, including the CPU and cache, is powered down.
Thanx, Paul
On Sun, Aug 01, 2010 at 03:41:57PM -0400, Alan Stern 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.
> > >
> > > 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.
>
> 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?
> > > > 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.
>
> Arjan's point here is well taken. Even systems that always run on
> external power have motivation for conserving energy (e.g., they may
> be required by government regulation to do so).
Indeed! However, my observation is that many of the battery-powered
embedded folks are much more aggressive in pursuit of energy efficiency
than are most of the server/desktop/laptop folks. Both have motivation,
but the degree of motivation can differ.
> > > > 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.
>
> 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?
> > > > 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?
>
> Sure.
K, done.
> > > > 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.
>
> Then state it immediately after the definition as an implication of
> the definition, not as a separate system requirement.
I am OK with that, and have moved it.
> > > > 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.
>
> 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?
> > > > 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?
>
> Change the last phrase to "regardless of the state of power-naive
> applications".
Done!
Thanx, Paul
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".
> > 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.
> > > 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.
Alan Stern
> > > 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".
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. 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.
- Ted
On Sunday, August 01, 2010, Paul E. McKenney wrote:
> On Sun, Aug 01, 2010 at 05:41:30PM +0200, Rafael J. Wysocki wrote:
> > On Saturday, July 31, 2010, Alan Stern wrote:
> > > On Sat, 31 Jul 2010, Paul E. McKenney wrote:
...
> > > 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.
>
> Fair enough. It appears to me that Android won't suspend if the display
> is on, but I could easily be confused here.
That's correct. In fact, Android uses a special mechanism called "early
suspend" (or similar) to suspend the display and some other devices before the
"real" suspend happens.
...
> > > > 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.
>
> OK, but I still believe that an enforcement mechanism is required.
The requirement is that power-oblivious applications should not participate
in deciding whether or not to put the system into a sleep state which is pretty
much by definition.
> > > > 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.
>
> Again, this requirement was explicitly called out by the Android folks.
Rather, there should be a mechanism allowing PM-driving applications to do
that, but they are not required to use that mechanism.
Thanks,
Rafael
On Sun, 1 Aug 2010 12:12:28 -0700
"Paul E. McKenney" <[email protected]> wrote:
> 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.
>
power indeed needs multiple approaches. For example the timer work you
mention. What the timer work allows is controlling the behavior of
applications that are not well behaved. This is an important way of
driving progress, one the android guys sort of swept under the table.
Is the flash plugin (which seems to be the most popular and also worst
behaving software in these type of discussions) waking up 100 times per
second? <small adjustment by a policy manager> ... now it's only waking
up once every 10 seconds, or when something else causes system activity
anyway.
That capability is there in Linux today, and has been there for a long
time now. It's highly underused unfortunately... at least outside the
MeeGo world of Linux distributions.
Another one: freezing whole cgroups..... we have that today. it
actually works quite well.... of course the hard part is the decision
what to put in which cgroup, and at what frequency and duration you let
cgroups run.
on the suspend blockers for drivers; the linux device runtime PM is
effectively doing the same things; it allows drivers to suspend/resume
individually (with a very nice API/programming model I should say) based
on usage. And it works on a tree level, so that it's relatively easy
to do things like "I want to go to <this magic deep idle state>, but
only if <this set of devices is suspended already>". This is obviously
an important functionality for all low power devices, ARM or x86.
Suspend blockers had this functionality as part of what it did (they do
more obviously) but I'd wager that the current Linux infrastructure is
outright nicer.
It's what I want to be using for the Intel phone silicon (which isn't
all that different in power behavior/requirements than ARM based
silicon), and I need to thank Qualcomm here for providing some very
good patches to the kernel to allow this model to work for this
scenario.
As for the aware-versus-good-behaving point; applications can be aware,
and yet bad behaving, and can be unaware but good behaving. You don't
like me saying this, but the reality is that the behavior matters in
the end. *AND WE OBSERVE THIS BEHAVIOR*. It's not hard to move a
program/task/whatever from a "behaves well, let run unrestricted" to a
"doesn't behave well, needs its behavior adjusted" list and back, just
from its behavior. PowerTOP observes such apps. Android has an
equivalent thing that observes app behavior. It's not all that hard to
detect such things.... and the result is much better than some static
"aware" flag one can tag an application with. The "aware" flag
indicates that there is a "before" and an "after", and that that's it.
Reality isn't so black and white as you stated, but that goes for both
sides. Observing *current* behavior is much more powerful.
Is the part of the app you use fine, even though some function you
don't use behave badly? No problem, you get it categorized with the
good guys. Is an app 98% working clean, but you on your phone like
using the 2% all the time? it's moved to the "must get its attitude
adjusted" list.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sun, 1 Aug 2010 12:27:08 -0700
"Paul E. McKenney" <[email protected]> wrote:
> On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote:
> > 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.
>
> Good points in both this and your earlier post!!!
>
> > 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.
>
> This is a good point. Within some limits, the timer-aggregation
> changes that have gone into Linux can handle this, but I am not sure
> whether or not 180 seconds is within the reasonable boundaries for
> timer jitter.
this is why operating systems for mobile devices offer heartbeat
services... where apps subscribe to and do background work like
checking email at "convenient" times.
I'm not sure if the OS you use on your desktop has one, but MeeGo and
Maemo and I'm pretty sure Android and most other mobile Linux OSes have
one. It's a higher level activity alignment layer, well above the
kernel.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
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
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
On Mon, 2 Aug 2010 01:02:24 +0200
"Rafael J. Wysocki" <[email protected]> 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....
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" <[email protected]> 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
> 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
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
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
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
On Mon, Aug 02, 2010 at 12:44:56AM +0200, Rafael J. Wysocki wrote:
> On Sunday, August 01, 2010, Paul E. McKenney wrote:
> > On Sun, Aug 01, 2010 at 05:41:30PM +0200, Rafael J. Wysocki wrote:
> > > On Saturday, July 31, 2010, Alan Stern wrote:
> > > > On Sat, 31 Jul 2010, Paul E. McKenney wrote:
> ...
> > > > 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.
> >
> > Fair enough. It appears to me that Android won't suspend if the display
> > is on, but I could easily be confused here.
>
> That's correct. In fact, Android uses a special mechanism called "early
> suspend" (or similar) to suspend the display and some other devices before the
> "real" suspend happens.
Sounds good!
> ...
> > > > > 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.
> >
> > OK, but I still believe that an enforcement mechanism is required.
>
> The requirement is that power-oblivious applications should not participate
> in deciding whether or not to put the system into a sleep state which is pretty
> much by definition.
I moved this into the definitions section -- you and Alan convince me. ;-)
> > > > > 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.
> >
> > Again, this requirement was explicitly called out by the Android folks.
>
> Rather, there should be a mechanism allowing PM-driving applications to do
> that, but they are not required to use that mechanism.
Fair enough! I moved this into a new section that I am currently calling
"SUGGESTED USAGE".
Thanx, Paul
On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 12:12:28 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>
> > 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.
>
> power indeed needs multiple approaches. For example the timer work you
> mention. What the timer work allows is controlling the behavior of
> applications that are not well behaved. This is an important way of
> driving progress, one the android guys sort of swept under the table.
>
> Is the flash plugin (which seems to be the most popular and also worst
> behaving software in these type of discussions) waking up 100 times per
> second? <small adjustment by a policy manager> ... now it's only waking
> up once every 10 seconds, or when something else causes system activity
> anyway.
>
> That capability is there in Linux today, and has been there for a long
> time now. It's highly underused unfortunately... at least outside the
> MeeGo world of Linux distributions.
I agree that timer control is important and will continue to be.
It doesn't seem to me to be in conflict with the Android guys' approach,
in fact, it should help reduce power consumption while the device
is active. I might well be missing something, though.
> Another one: freezing whole cgroups..... we have that today. it
> actually works quite well.... of course the hard part is the decision
> what to put in which cgroup, and at what frequency and duration you let
> cgroups run.
Indeed, the Android guys seemed to be quite excited by cgroup freezing
until they thought about the application-classification problem.
Seems like it should be easy for some types of applications, but I do
admit that apps can have non-trivial and non-obvious dependencies.
> on the suspend blockers for drivers; the linux device runtime PM is
> effectively doing the same things; it allows drivers to suspend/resume
> individually (with a very nice API/programming model I should say) based
> on usage. And it works on a tree level, so that it's relatively easy
> to do things like "I want to go to <this magic deep idle state>, but
> only if <this set of devices is suspended already>". This is obviously
> an important functionality for all low power devices, ARM or x86.
> Suspend blockers had this functionality as part of what it did (they do
> more obviously) but I'd wager that the current Linux infrastructure is
> outright nicer.
This is what Rafael has been working on?
Of course, the Android guys also want to pay attention to which apps
are running as well as to the state of devices on the system.
> It's what I want to be using for the Intel phone silicon (which isn't
> all that different in power behavior/requirements than ARM based
> silicon), and I need to thank Qualcomm here for providing some very
> good patches to the kernel to allow this model to work for this
> scenario.
I must have missed those, and I am not seeing any obvious commits
in v2.6.35-rc6. Would you be willing to send a pointer?
> As for the aware-versus-good-behaving point; applications can be aware,
> and yet bad behaving, and can be unaware but good behaving. You don't
> like me saying this, but the reality is that the behavior matters in
> the end. *AND WE OBSERVE THIS BEHAVIOR*. It's not hard to move a
> program/task/whatever from a "behaves well, let run unrestricted" to a
> "doesn't behave well, needs its behavior adjusted" list and back, just
> from its behavior. PowerTOP observes such apps. Android has an
> equivalent thing that observes app behavior. It's not all that hard to
> detect such things.... and the result is much better than some static
> "aware" flag one can tag an application with. The "aware" flag
> indicates that there is a "before" and an "after", and that that's it.
> Reality isn't so black and white as you stated, but that goes for both
> sides. Observing *current* behavior is much more powerful.
> Is the part of the app you use fine, even though some function you
> don't use behave badly? No problem, you get it categorized with the
> good guys. Is an app 98% working clean, but you on your phone like
> using the 2% all the time? it's moved to the "must get its attitude
> adjusted" list.
If I understand you correctly, a key point of agreement between you and
the Android guys is that both the system and the user have some say over
how applications are treated by the system in terms of how seriously
the system takes a given application's requests.
The Android guys also want the user to have some say about what
applications are permitted to have some control over "I want to go to
<this magic deep idle state>" requests. Does that seem reasonable
to you?
Thanx, Paul
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" <[email protected]> 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
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
On Sun, Aug 01, 2010 at 03:49:04PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 12:27:08 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>
> > On Sun, Aug 01, 2010 at 08:49:43AM +0200, Mikael Abrahamsson wrote:
> > > 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.
> >
> > Good points in both this and your earlier post!!!
> >
> > > 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.
> >
> > This is a good point. Within some limits, the timer-aggregation
> > changes that have gone into Linux can handle this, but I am not sure
> > whether or not 180 seconds is within the reasonable boundaries for
> > timer jitter.
>
> this is why operating systems for mobile devices offer heartbeat
> services... where apps subscribe to and do background work like
> checking email at "convenient" times.
>
> I'm not sure if the OS you use on your desktop has one, but MeeGo and
> Maemo and I'm pretty sure Android and most other mobile Linux OSes have
> one. It's a higher level activity alignment layer, well above the
> kernel.
Thank you, good to know!
Thanx, Paul
On Sun, 1 Aug 2010 18:10:06 -0700
"Paul E. McKenney" <[email protected]> wrote:
> If I understand you correctly, a key point of agreement between you
> and the Android guys is that both the system and the user have some
> say over how applications are treated by the system in terms of how
> seriously the system takes a given application's requests.
>
> The Android guys also want the user to have some say about what
> applications are permitted to have some control over "I want to go to
> <this magic deep idle state>" requests. Does that seem reasonable
> to you?
I personally think it's one of those things where... well we can get a
LONG way automatically (by just observing things); asking the users
is very very often just caving in rather than solving the problem.
Asking the user should only be done for things the user
1) Can give an intelligent answer to
and
2) Are something the user WANTS to be involved in.
(rather than 'stupid thing, why don't just do the right thing'..
think the Windows Vista security questions)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sun, 1 Aug 2010 20:03:04 -0700
"Paul E. McKenney" <[email protected]> wrote:
> > 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.
we have a few things going for us here though
1) It's easy to programatically detect the problems
1a) so programmers can detect issues before they ship software,
unlike the fsync() thing Ted mentions. History is showing this is at
least relatively successful in open source, but not with Adobe's
proprietary software such as Flash
2) Users can be made aware of what the bad guys are
3) The business models of many of the mobile apps gives programmers a
strong incentive to ship well behaving. The moment your first and
second review of your app read "this app was identified as reducing
battery life a lot"... your revenues will not go beyond the $1.98..
... assuming these first two guys didn't refund their app.
Since we can detect who the bad guys are, we can also automatically
quarantine them for the common cases..... which is good news.
I'm a little worried that this whole "I need to block suspend" is
temporary. Yes today there is silicon from ARM and Intel where suspend
is a heavy operation, yet at the same time it's not all THAT heavy
anymore.... at least on the Intel side it's good enough to use pretty
much all the time (when the screen is off for now, but that's a memory
controller issue more than anything else). I'm pretty sure the ARM guys
will not be far behind.
On Sun, 1 Aug 2010, Arjan van de Ven wrote:
> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore.... at least on the Intel side it's good enough to use pretty
> much all the time (when the screen is off for now, but that's a memory
> controller issue more than anything else). I'm pretty sure the ARM guys
> will not be far behind.
remember that this 'block suspend' is really 'block overriding the fact
that there are still runable processes and suspending anyway"
having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
as if it blocks any attempt to suspend, and I'm not sure that's what's
really intended. Itsounds like the normal syspend process would continue
to work, just this 'ignore if these other apps are busy' mode of operation
would not work.
which makes me wonder, would it be possible to tell the normal idle
detection mechanism to ignore specific processes when deciding if it
should suspend or not? how about only considering processes in one cgroup
when deciding to suspend and ignoring all others?
David Lang
Hi,
On Sun, 1 Aug 2010 21:05:48 -0700
Arjan van de Ven <[email protected]> wrote:
> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore.... at least on the Intel side it's good enough to use pretty
> much all the time (when the screen is off for now, but that's a memory
> controller issue more than anything else). I'm pretty sure the ARM guys
> will not be far behind.
I think that the only thing that really matters (longterm) with suspend
is that processes don't get scheduled anymore when the system is
suspended.
Cheers,
Flo
On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
[email protected] wrote:
> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>
> > I'm a little worried that this whole "I need to block suspend" is
> > temporary. Yes today there is silicon from ARM and Intel where suspend
> > is a heavy operation, yet at the same time it's not all THAT heavy
> > anymore.... at least on the Intel side it's good enough to use pretty
> > much all the time (when the screen is off for now, but that's a memory
> > controller issue more than anything else). I'm pretty sure the ARM guys
> > will not be far behind.
>
> remember that this 'block suspend' is really 'block overriding the fact
> that there are still runable processes and suspending anyway"
>
> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
> as if it blocks any attempt to suspend, and I'm not sure that's what's
> really intended. Itsounds like the normal syspend process would continue
> to work, just this 'ignore if these other apps are busy' mode of operation
> would not work.
>
> which makes me wonder, would it be possible to tell the normal idle
> detection mechanism to ignore specific processes when deciding if it
> should suspend or not? how about only considering processes in one cgroup
> when deciding to suspend and ignoring all others?
>
> David Lang
We then get again to the "runnable tasks" problem that was
discussed earlier... the system get's "deadlock-prone" if a subset of
tasks is not run.
Interprocess dependencies are not so easy to get right in general.
Cheers,
Flo
On Mon, 2 Aug 2010, Florian Mickler wrote:
> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
> [email protected] wrote:
>
>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>>
>>> I'm a little worried that this whole "I need to block suspend" is
>>> temporary. Yes today there is silicon from ARM and Intel where suspend
>>> is a heavy operation, yet at the same time it's not all THAT heavy
>>> anymore.... at least on the Intel side it's good enough to use pretty
>>> much all the time (when the screen is off for now, but that's a memory
>>> controller issue more than anything else). I'm pretty sure the ARM guys
>>> will not be far behind.
>>
>> remember that this 'block suspend' is really 'block overriding the fact
>> that there are still runable processes and suspending anyway"
>>
>> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
>> as if it blocks any attempt to suspend, and I'm not sure that's what's
>> really intended. Itsounds like the normal syspend process would continue
>> to work, just this 'ignore if these other apps are busy' mode of operation
>> would not work.
>>
>> which makes me wonder, would it be possible to tell the normal idle
>> detection mechanism to ignore specific processes when deciding if it
>> should suspend or not? how about only considering processes in one cgroup
>> when deciding to suspend and ignoring all others?
>>
>> David Lang
>
> We then get again to the "runnable tasks" problem that was
> discussed earlier... the system get's "deadlock-prone" if a subset of
> tasks is not run.
> Interprocess dependencies are not so easy to get right in general.
I'm not suggesting that you don't run the 'untrusted' tasks, just that you
don't consider them when deciding if the system can suspend or not. if the
system is awake, everything runs, if the system is idle (except for the
activity of the 'untrusted' tasks) you suspend normally.
David Lang
On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
[email protected] wrote:
> On Mon, 2 Aug 2010, Florian Mickler wrote:
>
> > On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
> > [email protected] wrote:
> >
> >> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
> >>
> >>> I'm a little worried that this whole "I need to block suspend" is
> >>> temporary. Yes today there is silicon from ARM and Intel where suspend
> >>> is a heavy operation, yet at the same time it's not all THAT heavy
> >>> anymore.... at least on the Intel side it's good enough to use pretty
> >>> much all the time (when the screen is off for now, but that's a memory
> >>> controller issue more than anything else). I'm pretty sure the ARM guys
> >>> will not be far behind.
> >>
> >> remember that this 'block suspend' is really 'block overriding the fact
> >> that there are still runable processes and suspending anyway"
> >>
> >> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
> >> as if it blocks any attempt to suspend, and I'm not sure that's what's
> >> really intended. Itsounds like the normal syspend process would continue
> >> to work, just this 'ignore if these other apps are busy' mode of operation
> >> would not work.
> >>
> >> which makes me wonder, would it be possible to tell the normal idle
> >> detection mechanism to ignore specific processes when deciding if it
> >> should suspend or not? how about only considering processes in one cgroup
> >> when deciding to suspend and ignoring all others?
> >>
> >> David Lang
> >
> > We then get again to the "runnable tasks" problem that was
> > discussed earlier... the system get's "deadlock-prone" if a subset of
> > tasks is not run.
> > Interprocess dependencies are not so easy to get right in general.
>
> I'm not suggesting that you don't run the 'untrusted' tasks, just that you
> don't consider them when deciding if the system can suspend or not. if the
> system is awake, everything runs, if the system is idle (except for the
> activity of the 'untrusted' tasks) you suspend normally.
>
> David Lang
Ah, yes. Sorry. It's pretty early in the morning over here, I don't
seem to have my eyes fully opened yet... A "ignore-these-processes"
cgroup could probably work... It would have the advantage of not having
to maintain a special purpose API....
Cheers,
Flo
On Mon, 2 Aug 2010 08:40:03 +0200
Florian Mickler <[email protected]> wrote:
> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
> [email protected] wrote:
>
> > On Mon, 2 Aug 2010, Florian Mickler wrote:
> >
> > > On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
> > > [email protected] wrote:
> > >
> > >> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
> > >>
> > >>> I'm a little worried that this whole "I need to block suspend" is
> > >>> temporary. Yes today there is silicon from ARM and Intel where suspend
> > >>> is a heavy operation, yet at the same time it's not all THAT heavy
> > >>> anymore.... at least on the Intel side it's good enough to use pretty
> > >>> much all the time (when the screen is off for now, but that's a memory
> > >>> controller issue more than anything else). I'm pretty sure the ARM guys
> > >>> will not be far behind.
> > >>
> > >> remember that this 'block suspend' is really 'block overriding the fact
> > >> that there are still runable processes and suspending anyway"
> > >>
> > >> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
> > >> as if it blocks any attempt to suspend, and I'm not sure that's what's
> > >> really intended. Itsounds like the normal syspend process would continue
> > >> to work, just this 'ignore if these other apps are busy' mode of operation
> > >> would not work.
> > >>
> > >> which makes me wonder, would it be possible to tell the normal idle
> > >> detection mechanism to ignore specific processes when deciding if it
> > >> should suspend or not? how about only considering processes in one cgroup
> > >> when deciding to suspend and ignoring all others?
> > >>
> > >> David Lang
> > >
> > > We then get again to the "runnable tasks" problem that was
> > > discussed earlier... the system get's "deadlock-prone" if a subset of
> > > tasks is not run.
> > > Interprocess dependencies are not so easy to get right in general.
> >
> > I'm not suggesting that you don't run the 'untrusted' tasks, just that you
> > don't consider them when deciding if the system can suspend or not. if the
> > system is awake, everything runs, if the system is idle (except for the
> > activity of the 'untrusted' tasks) you suspend normally.
> >
> > David Lang
>
> Ah, yes. Sorry. It's pretty early in the morning over here, I don't
> seem to have my eyes fully opened yet... A "ignore-these-processes"
> cgroup could probably work... It would have the advantage of not having
> to maintain a special purpose API....
>
>
> Cheers,
> Flo
>
Thinking about it.. I don't know much about cgroups, but I think a
process can only be in one cgroup at a time. So you'd need to provide
a) a way to race free migrate them to the "suspend block" cgroup (or
dropping them out of the "ignore" cgroup)
b) you can't use cgroup for other purposes anymore. I.e. if you want to
have 2 groups that each only have half of the memory available, how
would you then integrate the cgroup-ignore-for-idle-approach with this?
hmmm..
Cheers,
Flo
On Mon, 2 Aug 2010, Florian Mickler wrote:
> On Mon, 2 Aug 2010 08:40:03 +0200
> Florian Mickler <[email protected]> wrote:
>
>> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
>> [email protected] wrote:
>>
>>> On Mon, 2 Aug 2010, Florian Mickler wrote:
>>>
>>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
>>>> [email protected] wrote:
>>>>
>>>>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>>>>>
>>>>>> I'm a little worried that this whole "I need to block suspend" is
>>>>>> temporary. Yes today there is silicon from ARM and Intel where suspend
>>>>>> is a heavy operation, yet at the same time it's not all THAT heavy
>>>>>> anymore.... at least on the Intel side it's good enough to use pretty
>>>>>> much all the time (when the screen is off for now, but that's a memory
>>>>>> controller issue more than anything else). I'm pretty sure the ARM guys
>>>>>> will not be far behind.
>>>>>
>>>>> remember that this 'block suspend' is really 'block overriding the fact
>>>>> that there are still runable processes and suspending anyway"
>>>>>
>>>>> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
>>>>> as if it blocks any attempt to suspend, and I'm not sure that's what's
>>>>> really intended. Itsounds like the normal syspend process would continue
>>>>> to work, just this 'ignore if these other apps are busy' mode of operation
>>>>> would not work.
>>>>>
>>>>> which makes me wonder, would it be possible to tell the normal idle
>>>>> detection mechanism to ignore specific processes when deciding if it
>>>>> should suspend or not? how about only considering processes in one cgroup
>>>>> when deciding to suspend and ignoring all others?
>>>>>
>>>>> David Lang
>>>>
>>>> We then get again to the "runnable tasks" problem that was
>>>> discussed earlier... the system get's "deadlock-prone" if a subset of
>>>> tasks is not run.
>>>> Interprocess dependencies are not so easy to get right in general.
>>>
>>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you
>>> don't consider them when deciding if the system can suspend or not. if the
>>> system is awake, everything runs, if the system is idle (except for the
>>> activity of the 'untrusted' tasks) you suspend normally.
>>>
>>> David Lang
>>
>> Ah, yes. Sorry. It's pretty early in the morning over here, I don't
>> seem to have my eyes fully opened yet... A "ignore-these-processes"
>> cgroup could probably work... It would have the advantage of not having
>> to maintain a special purpose API....
>>
>>
>> Cheers,
>> Flo
>>
>
> Thinking about it.. I don't know much about cgroups, but I think a
> process can only be in one cgroup at a time. So you'd need to provide
>
> a) a way to race free migrate them to the "suspend block" cgroup (or
> dropping them out of the "ignore" cgroup)
why does it need to be race free? being in transition is going to be
logically the same as being in the other group.
it's not like applications will be moving back and forth between the two
groups is it? I expect that this would be a one-time thing at startup.
> b) you can't use cgroup for other purposes anymore. I.e. if you want to
> have 2 groups that each only have half of the memory available, how
> would you then integrate the cgroup-ignore-for-idle-approach with this?
two answers to this
1. does this matter? do you really need to combine this 'suspend, even if
there are processes trying to run' with other cgroup limitations?
2. who says that this must be limited to one cgroup? a cgroup can have
several different flags/limits set on it, so why can't one of them be this
'ignore for suspend' flag?
these seem like simple issues, what I don't know is if it's possible for
the process that controlls suspend to follow such a flag without major
surgury on it's innards (if it can, this seems like a easy win, but I can
imagine internal designs where the software just knows that _something_ is
trying to run and would have a very hard time figuring out what)
David Lang
On Mon, 2 Aug 2010 00:02:04 -0700 (PDT)
[email protected] wrote:
> On Mon, 2 Aug 2010, Florian Mickler wrote:
>
> > On Mon, 2 Aug 2010 08:40:03 +0200
> > Florian Mickler <[email protected]> wrote:
> >
> >> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
> >> [email protected] wrote:
> >>
> >>> On Mon, 2 Aug 2010, Florian Mickler wrote:
> >>>
> >>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
> >>>> [email protected] wrote:
> >>>>
> >>>>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
> >>>>>
> >>>>>> I'm a little worried that this whole "I need to block suspend" is
> >>>>>> temporary. Yes today there is silicon from ARM and Intel where suspend
> >>>>>> is a heavy operation, yet at the same time it's not all THAT heavy
> >>>>>> anymore.... at least on the Intel side it's good enough to use pretty
> >>>>>> much all the time (when the screen is off for now, but that's a memory
> >>>>>> controller issue more than anything else). I'm pretty sure the ARM guys
> >>>>>> will not be far behind.
> >>>>>
> >>>>> remember that this 'block suspend' is really 'block overriding the fact
> >>>>> that there are still runable processes and suspending anyway"
> >>>>>
> >>>>> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
> >>>>> as if it blocks any attempt to suspend, and I'm not sure that's what's
> >>>>> really intended. Itsounds like the normal syspend process would continue
> >>>>> to work, just this 'ignore if these other apps are busy' mode of operation
> >>>>> would not work.
> >>>>>
> >>>>> which makes me wonder, would it be possible to tell the normal idle
> >>>>> detection mechanism to ignore specific processes when deciding if it
> >>>>> should suspend or not? how about only considering processes in one cgroup
> >>>>> when deciding to suspend and ignoring all others?
> >>>>>
> >>>>> David Lang
> >>>>
> >>>> We then get again to the "runnable tasks" problem that was
> >>>> discussed earlier... the system get's "deadlock-prone" if a subset of
> >>>> tasks is not run.
> >>>> Interprocess dependencies are not so easy to get right in general.
> >>>
> >>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you
> >>> don't consider them when deciding if the system can suspend or not. if the
> >>> system is awake, everything runs, if the system is idle (except for the
> >>> activity of the 'untrusted' tasks) you suspend normally.
> >>>
> >>> David Lang
> >>
> >> Ah, yes. Sorry. It's pretty early in the morning over here, I don't
> >> seem to have my eyes fully opened yet... A "ignore-these-processes"
> >> cgroup could probably work... It would have the advantage of not having
> >> to maintain a special purpose API....
> >>
> >>
> >> Cheers,
> >> Flo
> >>
> >
> > Thinking about it.. I don't know much about cgroups, but I think a
> > process can only be in one cgroup at a time. So you'd need to provide
> >
> > a) a way to race free migrate them to the "suspend block" cgroup (or
> > dropping them out of the "ignore" cgroup)
>
> why does it need to be race free? being in transition is going to be
> logically the same as being in the other group.
>
> it's not like applications will be moving back and forth between the two
> groups is it? I expect that this would be a one-time thing at startup.
hmm... i envisioned a mechanism where applications would be able to
switch the groups freely depending on what context the device is in.
I didn't even thought about a static grouping. But maybe that is
possible also and maybe even sufficient...
Anyway... right. This is probably not a show-stopper.
> > b) you can't use cgroup for other purposes anymore. I.e. if you want to
> > have 2 groups that each only have half of the memory available, how
> > would you then integrate the cgroup-ignore-for-idle-approach with this?
>
> two answers to this
>
> 1. does this matter? do you really need to combine this 'suspend, even if
> there are processes trying to run' with other cgroup limitations?
>
> 2. who says that this must be limited to one cgroup? a cgroup can have
> several different flags/limits set on it, so why can't one of them be this
> 'ignore for suspend' flag?
>
> these seem like simple issues, what I don't know is if it's possible for
> the process that controlls suspend to follow such a flag without major
> surgury on it's innards (if it can, this seems like a easy win, but I can
> imagine internal designs where the software just knows that _something_ is
> trying to run and would have a very hard time figuring out what)
>
> David Lang
Well, i fear it becomes some sort of parallel-tree structure...
If you want a cgroups-partitioning for one kind of attribute you now
need 2 containers for every possible stamping of that attribute... one
being flagged with 'ignore-for-suspend-decision' and one without that
flag.
Do you see what I'm getting at, or do I need more coffee and it is
irelevant to this concept?
Cheers,
Flo
On Mon, 2 Aug 2010, Florian Mickler wrote:
> On Mon, 2 Aug 2010 00:02:04 -0700 (PDT)
> [email protected] wrote:
>
>> On Mon, 2 Aug 2010, Florian Mickler wrote:
>>
>>> On Mon, 2 Aug 2010 08:40:03 +0200
>>> Florian Mickler <[email protected]> wrote:
>>>
>>>> On Sun, 1 Aug 2010 23:06:08 -0700 (PDT)
>>>> [email protected] wrote:
>>>>
>>>>> On Mon, 2 Aug 2010, Florian Mickler wrote:
>>>>>
>>>>>> On Sun, 1 Aug 2010 22:06:34 -0700 (PDT)
>>>>>> [email protected] wrote:
>>>>>>
>>>>>>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>>>>>>>
>>>>>>>> I'm a little worried that this whole "I need to block suspend" is
>>>>>>>> temporary. Yes today there is silicon from ARM and Intel where suspend
>>>>>>>> is a heavy operation, yet at the same time it's not all THAT heavy
>>>>>>>> anymore.... at least on the Intel side it's good enough to use pretty
>>>>>>>> much all the time (when the screen is off for now, but that's a memory
>>>>>>>> controller issue more than anything else). I'm pretty sure the ARM guys
>>>>>>>> will not be far behind.
>>>>>>>
>>>>>>> remember that this 'block suspend' is really 'block overriding the fact
>>>>>>> that there are still runable processes and suspending anyway"
>>>>>>>
>>>>>>> having it labeled as 'suspend blocker' or even 'wakelock' makes it sound
>>>>>>> as if it blocks any attempt to suspend, and I'm not sure that's what's
>>>>>>> really intended. Itsounds like the normal syspend process would continue
>>>>>>> to work, just this 'ignore if these other apps are busy' mode of operation
>>>>>>> would not work.
>>>>>>>
>>>>>>> which makes me wonder, would it be possible to tell the normal idle
>>>>>>> detection mechanism to ignore specific processes when deciding if it
>>>>>>> should suspend or not? how about only considering processes in one cgroup
>>>>>>> when deciding to suspend and ignoring all others?
>>>>>>>
>>>>>>> David Lang
>>>>>>
>>>>>> We then get again to the "runnable tasks" problem that was
>>>>>> discussed earlier... the system get's "deadlock-prone" if a subset of
>>>>>> tasks is not run.
>>>>>> Interprocess dependencies are not so easy to get right in general.
>>>>>
>>>>> I'm not suggesting that you don't run the 'untrusted' tasks, just that you
>>>>> don't consider them when deciding if the system can suspend or not. if the
>>>>> system is awake, everything runs, if the system is idle (except for the
>>>>> activity of the 'untrusted' tasks) you suspend normally.
>>>>>
>>> b) you can't use cgroup for other purposes anymore. I.e. if you want to
>>> have 2 groups that each only have half of the memory available, how
>>> would you then integrate the cgroup-ignore-for-idle-approach with this?
>>
>> two answers to this
>>
>> 1. does this matter? do you really need to combine this 'suspend, even if
>> there are processes trying to run' with other cgroup limitations?
>>
>> 2. who says that this must be limited to one cgroup? a cgroup can have
>> several different flags/limits set on it, so why can't one of them be this
>> 'ignore for suspend' flag?
>>
>> these seem like simple issues, what I don't know is if it's possible for
>> the process that controlls suspend to follow such a flag without major
>> surgury on it's innards (if it can, this seems like a easy win, but I can
>> imagine internal designs where the software just knows that _something_ is
>> trying to run and would have a very hard time figuring out what)
>>
>> David Lang
>
> Well, i fear it becomes some sort of parallel-tree structure...
> If you want a cgroups-partitioning for one kind of attribute you now
> need 2 containers for every possible stamping of that attribute... one
> being flagged with 'ignore-for-suspend-decision' and one without that
> flag.
> Do you see what I'm getting at, or do I need more coffee and it is
> irelevant to this concept?
yes, it could mean a doubleing in the number of cgroups that you need on a
system. and if there are other features like this you can end up in a
geometric explosion in the number of cgroups.
in practice I question if there is likely to be a need for this sort of
thing on a system that's complex enough to use cgroups for other purposes.
in particular, in this case the 'ignore for syspend' flag is not going to
be set for programs that are trusted to be well behaved. Such programs are
unlikely to be placed under other restraints (because they _are_ trusted
to be well behaved)
David Lang
On Sun, Aug 01, 2010 at 06:30:44PM -0500, James Bottomley wrote:
> 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.
Um, yes, that was deliberate. For some people I think people have
gotten hypersensitive about suspend blockers, to the point that I
think sometimes minds get closed automatically to say that suspend
blockers or their requirements are evil/not really a requirement, so I
decided to use another example other than scheduler control in the
hopes of pointing out (a) there is a more general problem, and (b)
application knows best is not enough, and (c) Arjan's claim that we
don't need to do anything because all applications should be written
to be "power optimized" and it shouldn't matter whether they are
connected to the AC mains or not is a vast oversimplification.
> 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.
Or they may decide to drop the device which has much worse battery
lifetime in favor of the hardware that seems to do a much better job
of controlling power overall... which is why if the Nokia folks want
to claim that suspend blockers are no good, it's probably not going to
change what ships with Android, and may be better power management
strategy win. :-)
> Right, but this comes back to the axes of control. They have to be
> presented to the user in a simple but meaningful manner.
In the general case, at least for today, I think it's useful if
applications are told, "you are on AC mains", "you are on cell phone
battery", "you are on a laptop battery". And from a user's
perspective, I suspect if you are wanting something simple but
meaningful, it's probably a single linear scale ranging between
"performance optimized" and "power optimized", with maybe 1-3
points in between.
Advanced users will want a much finer level of control, though --- I
can imagine having a number of different sliders that control the
tradeoff between power vs. performance on a number of different
scales: networking, GPS performance, scheduler control, schreen
brightness, etc.
Android phones have a very simplified version of this widget, which
allows you to toggle GPS on/off, bluetooth on/off, etc. And the GPS
toggle is a good example of what I'm talking about. If you disable
the GPS, then even if the application wants to use GPS, tough luck; it
will have to settle for the less precise cell tower triangulation
method. Again, it's the _user_ who gets the final say, not the
application --- and that's as it should be.
- Ted
On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore....
Part of the problem here may also be a naming problem. There are
multiple reasons why you might want to block suspend, and it goes far
beyond what the CPU can do.
Let's give another example, from the laptop world. If you close the
the MacBook, it "suspends". That is, all processes stop, and the CPU
enters a sleep state. Sounds just like Linux's suspend-to-ram, right?
Except for the fact that if you insert a USB cable connected to a
iPod/iPad/iPhone, the CPU wakes up, and iTunes will do a sync, and
then the machine goes back to sleep. And if the Mail application is
in the middle of manipulating the IMAP mailbox, it will be allowed to
finish what it is doing, and then the system goes to sleep.
So in the case of both the MacBook, where the user has closed the
laptop, and in the case of Cell Phone, where the user has pushed the
button saying he/she's done working with the application, the _normal_
thing to do force all processes to go to sleep, and then let the CPU
go to sleep.
But, you may have applications that are specially privileged so they
can ignore the user command to suspend the machine. Maybe it's an
iTunes-like situation, where in response to some hardware interrupt,
it's allowed to wake up, do its thing, and then go back to sleep,
allowing the hardware to go back to sleep. Maybe it's a mail
application that wants to wakeup every 15 minutes, suck down any new
mail, and then go back to sleep. The suspend blocker is a way to
achieve this --- and this has nothing to do with chip technology, but
with a specific use case.
- Ted
On Monday, August 02, 2010, Paul E. McKenney wrote:
> On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > On Sun, 1 Aug 2010 12:12:28 -0700
> > "Paul E. McKenney" <[email protected]> wrote:
...
> > Another one: freezing whole cgroups..... we have that today. it
> > actually works quite well.... of course the hard part is the decision
> > what to put in which cgroup, and at what frequency and duration you let
> > cgroups run.
>
> Indeed, the Android guys seemed to be quite excited by cgroup freezing
> until they thought about the application-classification problem.
> Seems like it should be easy for some types of applications, but I do
> admit that apps can have non-trivial and non-obvious dependencies.
This isn't more difficult than deciding which applications will be allowed to
use wakelocks (in the wakelocks world). It actually seems to be pretty much
equivalent to me. :-)
> > on the suspend blockers for drivers; the linux device runtime PM is
> > effectively doing the same things; it allows drivers to suspend/resume
> > individually (with a very nice API/programming model I should say) based
> > on usage. And it works on a tree level, so that it's relatively easy
> > to do things like "I want to go to <this magic deep idle state>, but
> > only if <this set of devices is suspended already>". This is obviously
> > an important functionality for all low power devices, ARM or x86.
> > Suspend blockers had this functionality as part of what it did (they do
> > more obviously) but I'd wager that the current Linux infrastructure is
> > outright nicer.
>
> This is what Rafael has been working on?
If you mean the runtime PM framework, then yes, I've been working on it.
> Of course, the Android guys also want to pay attention to which apps
> are running as well as to the state of devices on the system.
In fact the runtime PM framework is also important to Android, because it
can be used in there, for example, to implement the "early suspend" thing
I referred to in one of my previous messages in this thread.
Thanks,
Rafael
On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 20:03:04 -0700
> "Paul E. McKenney" <[email protected]> wrote:
> > > 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.
>
> we have a few things going for us here though
>
> 1) It's easy to programatically detect the problems
> 1a) so programmers can detect issues before they ship software,
> unlike the fsync() thing Ted mentions. History is showing this is at
> least relatively successful in open source, but not with Adobe's
> proprietary software such as Flash
> 2) Users can be made aware of what the bad guys are
> 3) The business models of many of the mobile apps gives programmers a
> strong incentive to ship well behaving. The moment your first and
> second review of your app read "this app was identified as reducing
> battery life a lot"... your revenues will not go beyond the $1.98..
> ... assuming these first two guys didn't refund their app.
>
> Since we can detect who the bad guys are, we can also automatically
> quarantine them for the common cases..... which is good news.
Unless of course the app reducing battery life a lot does something
that users like better than the increment in battery life.
> I'm a little worried that this whole "I need to block suspend" is
> temporary. Yes today there is silicon from ARM and Intel where suspend
> is a heavy operation, yet at the same time it's not all THAT heavy
> anymore.... at least on the Intel side it's good enough to use pretty
> much all the time (when the screen is off for now, but that's a memory
> controller issue more than anything else). I'm pretty sure the ARM guys
> will not be far behind.
Heh! One could make the "might be temporary" argument against any new
feature, including the ones that you are proposing. For but one example,
I very well remember being told by many people in many communities that
SMP was temporary -- Moore's-Law increases in clock frequency would soon
mean that even the biggest systems would be uniprocessors.
If by "memory controller" you are referring to the need to save state
for cache SRAMs and perhaps also DRAM, then yes, I agree that some of
the most difficult low-power-state tradeoffs involve these devices.
Thanx, Paul
On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>
> >I'm a little worried that this whole "I need to block suspend" is
> >temporary. Yes today there is silicon from ARM and Intel where suspend
> >is a heavy operation, yet at the same time it's not all THAT heavy
> >anymore.... at least on the Intel side it's good enough to use pretty
> >much all the time (when the screen is off for now, but that's a memory
> >controller issue more than anything else). I'm pretty sure the ARM guys
> >will not be far behind.
>
> remember that this 'block suspend' is really 'block overriding the
> fact that there are still runable processes and suspending anyway"
>
> having it labeled as 'suspend blocker' or even 'wakelock' makes it
> sound as if it blocks any attempt to suspend, and I'm not sure
> that's what's really intended. Itsounds like the normal syspend
> process would continue to work, just this 'ignore if these other
> apps are busy' mode of operation would not work.
>
> which makes me wonder, would it be possible to tell the normal idle
> detection mechanism to ignore specific processes when deciding if it
> should suspend or not? how about only considering processes in one
> cgroup when deciding to suspend and ignoring all others?
Why not flesh this out and compare it to the draft requirements?
(I expect to be sending another version by end of day Pacific Time.)
The biggest issue I see right off-hand is that a straightforward
implementation of your idea would require moving processes from one
cgroup to another when acquiring or releasing a suspend blocker, which
from what I understand would be way to heavyweight. On the other hand,
if acquiring and releasing a suspend blocker does not move the process
from one cgroup to another, then you need something very like the
suspend-blocker mechanism to handle those processes that are permitted
to acquire suspend blockers, and which are thus not a member of the
cgroup in question.
That said, I did see some hint from the Android guys that it -might-
be possible to leverage cgroups in the way that you suggest might help
save power during times when suspend was blocked but (for example) the
screen was turned off. The idea would be to freeze the cgroup whenever
the screen blanked, even if suspend was blocked. The biggest issue
here is that any process that can hold a suspend blocker must never to
an unconditional wait on any process in this cgroup. Seems to me that
this should be possible in theory, but the devil would be in the details.
If I am misunderstanding your proposal, please enlighten me!
Thanx, Paul
On Monday, August 02, 2010, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 09:05:48PM -0700, Arjan van de Ven wrote:
> > I'm a little worried that this whole "I need to block suspend" is
> > temporary. Yes today there is silicon from ARM and Intel where suspend
> > is a heavy operation, yet at the same time it's not all THAT heavy
> > anymore....
>
> Part of the problem here may also be a naming problem. There are
> multiple reasons why you might want to block suspend, and it goes far
> beyond what the CPU can do.
>
> Let's give another example, from the laptop world. If you close the
> the MacBook, it "suspends". That is, all processes stop, and the CPU
> enters a sleep state. Sounds just like Linux's suspend-to-ram, right?
>
> Except for the fact that if you insert a USB cable connected to a
> iPod/iPad/iPhone, the CPU wakes up, and iTunes will do a sync, and
> then the machine goes back to sleep. And if the Mail application is
> in the middle of manipulating the IMAP mailbox, it will be allowed to
> finish what it is doing, and then the system goes to sleep.
I _think_ you can implement that with the current kernel's interfaces and
an suitable power manager in user space. At least you should be.
The question really boils down to where the "power manager" activity should be
located. Should it be in the kernel or in user space? Or is it better to have
a "collective power manager", like in the wakelocks case? Moreover, what
should the power manager be responsible for and what the kernel's role should
be in deciding what "power" state to go into?
> So in the case of both the MacBook, where the user has closed the
> laptop, and in the case of Cell Phone, where the user has pushed the
> button saying he/she's done working with the application, the _normal_
> thing to do force all processes to go to sleep, and then let the CPU
> go to sleep.
>
> But, you may have applications that are specially privileged so they
> can ignore the user command to suspend the machine.
I frankly don't think it's legitimate to overrule the user. If the user tells
us "suspend" and specifies a set of devices that can be used for wakeup, we
should follow, possibly monitoring the wakeup devices for events.
However, that doesn't apply 100% to the cell phone case, because on cell phones
the software is actually owned by the device vendor and/or the network operator
and they may want to have a mechanism to overrule the person using the phone.
That is a more general issue, though.
> Maybe it's an iTunes-like situation, where in response to some hardware
> interrupt, it's allowed to wake up, do its thing, and then go back to sleep,
> allowing the hardware to go back to sleep. Maybe it's a mail
> application that wants to wakeup every 15 minutes, suck down any new
> mail, and then go back to sleep. The suspend blocker is a way to
> achieve this --- and this has nothing to do with chip technology, but
> with a specific use case.
Assuming that your "power manager activity" will be a collective one, along the
Android lines. Still, in principle, you can obtain a functionally equivalent
behavior with the help of a power manager in user space.
Thanks,
Rafael
On Sun, Aug 01, 2010 at 08:06:55PM -0700, Arjan van de Ven wrote:
> On Sun, 1 Aug 2010 18:10:06 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>
> > If I understand you correctly, a key point of agreement between you
> > and the Android guys is that both the system and the user have some
> > say over how applications are treated by the system in terms of how
> > seriously the system takes a given application's requests.
> >
> > The Android guys also want the user to have some say about what
> > applications are permitted to have some control over "I want to go to
> > <this magic deep idle state>" requests. Does that seem reasonable
> > to you?
>
> I personally think it's one of those things where... well we can get a
> LONG way automatically (by just observing things); asking the users
> is very very often just caving in rather than solving the problem.
>
> Asking the user should only be done for things the user
> 1) Can give an intelligent answer to
> and
> 2) Are something the user WANTS to be involved in.
> (rather than 'stupid thing, why don't just do the right thing'..
> think the Windows Vista security questions)
Combining this with your previous email, I believe that you are saying
that it is necessary for the user to be able to exert some control,
but that the UI design had better be sufficiently intelligent with
sufficiently good defaults that the user almost never actually -needs-
to exert such control.
If this is indeed what you are saying, I certainly agree.
Thanx, Paul
On Mon, 2010-08-02 at 08:12 -0400, Ted Ts'o wrote:
> On Sun, Aug 01, 2010 at 06:30:44PM -0500, James Bottomley wrote:
> > 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.
>
> Or they may decide to drop the device which has much worse battery
> lifetime in favor of the hardware that seems to do a much better job
> of controlling power overall... which is why if the Nokia folks want
> to claim that suspend blockers are no good, it's probably not going to
> change what ships with Android, and may be better power management
> strategy win. :-)
>
> > Right, but this comes back to the axes of control. They have to be
> > presented to the user in a simple but meaningful manner.
>
> In the general case, at least for today, I think it's useful if
> applications are told, "you are on AC mains", "you are on cell phone
> battery", "you are on a laptop battery". And from a user's
> perspective, I suspect if you are wanting something simple but
> meaningful, it's probably a single linear scale ranging between
> "performance optimized" and "power optimized", with maybe 1-3
> points in between.
Actually, I don't necessarily agree with this. In fact, I think it's a
dangerous proposition. The reason is that the only class of
applications I've seen usefully made power aware are some of the system
housekeeping ones (as in don't index my man pages, prelink my binaries
etc. when I'm on battery power). Perhaps I could see things that have
to poll (like imap without push support on the server) do a "poll when
woken else every X minutes", but the potential for annoying the user by
doing the wrong thing on power environment change is huge.
> Advanced users will want a much finer level of control, though --- I
> can imagine having a number of different sliders that control the
> tradeoff between power vs. performance on a number of different
> scales: networking, GPS performance, scheduler control, schreen
> brightness, etc.
>
> Android phones have a very simplified version of this widget, which
> allows you to toggle GPS on/off, bluetooth on/off, etc. And the GPS
> toggle is a good example of what I'm talking about. If you disable
> the GPS, then even if the application wants to use GPS, tough luck; it
> will have to settle for the less precise cell tower triangulation
> method. Again, it's the _user_ who gets the final say, not the
> application --- and that's as it should be.
Yes and no; agree about the user not the application but ... I actually
find the current five android "power" toggles to be largely useless. If
I don't want GPS killing my battery, I don't start GPS using
applications, for instance rather than disabling GPS. I think this
represents the "axis" problem again ... I like to manage my power in a
particular way, and others want to manage it in different ways.
James
On Mon, Aug 02, 2010 at 11:51:20AM -0500, James Bottomley wrote:
> Actually, I don't necessarily agree with this. In fact, I think it's a
> dangerous proposition. The reason is that the only class of
> applications I've seen usefully made power aware are some of the system
> housekeeping ones (as in don't index my man pages, prelink my binaries
> etc. when I'm on battery power). Perhaps I could see things that have
> to poll (like imap without push support on the server) do a "poll when
> woken else every X minutes", but the potential for annoying the user by
> doing the wrong thing on power environment change is huge.
Sure, but that's why you need to let the user choose. They can decide
between, "behave as if you were on AC", and "try to save power as much
as possible", and maybe one or two points in between, and let them
choose how much performance/battery life they are willing to give up.
If they are on a long flight to Europe/Australia with no power, they
might choose a very different tradeoff point than if they know they
are only going to be in the meeting room for an hour before they can
recharge their battery.
The point is you can annoy users by burning power to improve their
"user experience" just as much as you can annoy users by trying to sip
power as delicately as possible. It's true that many applications
don't do a lot in this space, but that's mainly becaue of application
laziness. Which is why I really don't buy Arjan's whack-a-mole
approach to solving the problem. I *know* I can save tons of power by
doing "killall -STOP firefox" when I don't need to use the browser.
I've don't the power management when I've been carefully nursing my
battery while at a conference. So I have no problem if the system
does that automatically for me when I switch to a different virtual
console --- in fact, I'd prefer it! Similarly, having tools which
forcibly choose different pm_qos settings, even if it's not what the
applications want, is things that *can* very much make a difference.
So yes, maybe applications won't do much with that. But that just
reinforces the argument that it's the framework or the kernel that
needs to do these sorts of things, because the application programers
won't.
- Ted
On Mon, Aug 02, 2010 at 03:52:20PM +0200, Rafael J. Wysocki wrote:
> On Monday, August 02, 2010, Paul E. McKenney wrote:
> > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > > On Sun, 1 Aug 2010 12:12:28 -0700
> > > "Paul E. McKenney" <[email protected]> wrote:
> ...
> > > Another one: freezing whole cgroups..... we have that today. it
> > > actually works quite well.... of course the hard part is the decision
> > > what to put in which cgroup, and at what frequency and duration you let
> > > cgroups run.
> >
> > Indeed, the Android guys seemed to be quite excited by cgroup freezing
> > until they thought about the application-classification problem.
> > Seems like it should be easy for some types of applications, but I do
> > admit that apps can have non-trivial and non-obvious dependencies.
>
> This isn't more difficult than deciding which applications will be allowed to
> use wakelocks (in the wakelocks world). It actually seems to be pretty much
> equivalent to me. :-)
If I understand correctly, the problem they were concerned about was
instead "given that a certain set of apps are permitted to use wakelocks,
which of the other apps can safely be frozen when the display blanks
itself."
> > > on the suspend blockers for drivers; the linux device runtime PM is
> > > effectively doing the same things; it allows drivers to suspend/resume
> > > individually (with a very nice API/programming model I should say) based
> > > on usage. And it works on a tree level, so that it's relatively easy
> > > to do things like "I want to go to <this magic deep idle state>, but
> > > only if <this set of devices is suspended already>". This is obviously
> > > an important functionality for all low power devices, ARM or x86.
> > > Suspend blockers had this functionality as part of what it did (they do
> > > more obviously) but I'd wager that the current Linux infrastructure is
> > > outright nicer.
> >
> > This is what Rafael has been working on?
>
> If you mean the runtime PM framework, then yes, I've been working on it.
>
> > Of course, the Android guys also want to pay attention to which apps
> > are running as well as to the state of devices on the system.
>
> In fact the runtime PM framework is also important to Android, because it
> can be used in there, for example, to implement the "early suspend" thing
> I referred to in one of my previous messages in this thread.
Now we just need to convince the Android guys of that. ;-)
Thanx, Paul
On Monday, August 02, 2010, Paul E. McKenney wrote:
> On Mon, Aug 02, 2010 at 03:52:20PM +0200, Rafael J. Wysocki wrote:
> > On Monday, August 02, 2010, Paul E. McKenney wrote:
> > > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > > > On Sun, 1 Aug 2010 12:12:28 -0700
> > > > "Paul E. McKenney" <[email protected]> wrote:
> > ...
> > > > Another one: freezing whole cgroups..... we have that today. it
> > > > actually works quite well.... of course the hard part is the decision
> > > > what to put in which cgroup, and at what frequency and duration you let
> > > > cgroups run.
> > >
> > > Indeed, the Android guys seemed to be quite excited by cgroup freezing
> > > until they thought about the application-classification problem.
> > > Seems like it should be easy for some types of applications, but I do
> > > admit that apps can have non-trivial and non-obvious dependencies.
> >
> > This isn't more difficult than deciding which applications will be allowed to
> > use wakelocks (in the wakelocks world). It actually seems to be pretty much
> > equivalent to me. :-)
>
> If I understand correctly, the problem they were concerned about was
> instead "given that a certain set of apps are permitted to use wakelocks,
> which of the other apps can safely be frozen when the display blanks
> itself."
I _think_ the problem should be reformulated as "which of the other apps
can be safely frozen without causing the wakelocks-using ones to have
problems" instead (the particular scenario is that one of the wakelocks-using
apps may need one of the other apps to process something and therefore the
other app cannot be frozen; however, that may be resolved by thawing all of
the other apps in such situations IMO).
> > > > on the suspend blockers for drivers; the linux device runtime PM is
> > > > effectively doing the same things; it allows drivers to suspend/resume
> > > > individually (with a very nice API/programming model I should say) based
> > > > on usage. And it works on a tree level, so that it's relatively easy
> > > > to do things like "I want to go to <this magic deep idle state>, but
> > > > only if <this set of devices is suspended already>". This is obviously
> > > > an important functionality for all low power devices, ARM or x86.
> > > > Suspend blockers had this functionality as part of what it did (they do
> > > > more obviously) but I'd wager that the current Linux infrastructure is
> > > > outright nicer.
> > >
> > > This is what Rafael has been working on?
> >
> > If you mean the runtime PM framework, then yes, I've been working on it.
> >
> > > Of course, the Android guys also want to pay attention to which apps
> > > are running as well as to the state of devices on the system.
> >
> > In fact the runtime PM framework is also important to Android, because it
> > can be used in there, for example, to implement the "early suspend" thing
> > I referred to in one of my previous messages in this thread.
>
> Now we just need to convince the Android guys of that. ;-)
I believe there's no need for that, as we were talking about that a few months
ago.
Thanks,
Rafael
On Mon, Aug 02, 2010 at 11:33:32PM +0200, Rafael J. Wysocki wrote:
> On Monday, August 02, 2010, Paul E. McKenney wrote:
> > On Mon, Aug 02, 2010 at 03:52:20PM +0200, Rafael J. Wysocki wrote:
> > > On Monday, August 02, 2010, Paul E. McKenney wrote:
> > > > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > > > > On Sun, 1 Aug 2010 12:12:28 -0700
> > > > > "Paul E. McKenney" <[email protected]> wrote:
> > > ...
> > > > > Another one: freezing whole cgroups..... we have that today. it
> > > > > actually works quite well.... of course the hard part is the decision
> > > > > what to put in which cgroup, and at what frequency and duration you let
> > > > > cgroups run.
> > > >
> > > > Indeed, the Android guys seemed to be quite excited by cgroup freezing
> > > > until they thought about the application-classification problem.
> > > > Seems like it should be easy for some types of applications, but I do
> > > > admit that apps can have non-trivial and non-obvious dependencies.
> > >
> > > This isn't more difficult than deciding which applications will be allowed to
> > > use wakelocks (in the wakelocks world). It actually seems to be pretty much
> > > equivalent to me. :-)
> >
> > If I understand correctly, the problem they were concerned about was
> > instead "given that a certain set of apps are permitted to use wakelocks,
> > which of the other apps can safely be frozen when the display blanks
> > itself."
>
> I _think_ the problem should be reformulated as "which of the other apps
> can be safely frozen without causing the wakelocks-using ones to have
> problems" instead (the particular scenario is that one of the wakelocks-using
> apps may need one of the other apps to process something and therefore the
> other app cannot be frozen; however, that may be resolved by thawing all of
> the other apps in such situations IMO).
I agree that your statement is equivalent to mine. From what I can see,
the current Android code resolves this by not freezing any app while
a wakelock is held.
Just out of curiosity, how are you detecting the situation in order to
decide when to thaw the apps in the cgroup?
> > > > > on the suspend blockers for drivers; the linux device runtime PM is
> > > > > effectively doing the same things; it allows drivers to suspend/resume
> > > > > individually (with a very nice API/programming model I should say) based
> > > > > on usage. And it works on a tree level, so that it's relatively easy
> > > > > to do things like "I want to go to <this magic deep idle state>, but
> > > > > only if <this set of devices is suspended already>". This is obviously
> > > > > an important functionality for all low power devices, ARM or x86.
> > > > > Suspend blockers had this functionality as part of what it did (they do
> > > > > more obviously) but I'd wager that the current Linux infrastructure is
> > > > > outright nicer.
> > > >
> > > > This is what Rafael has been working on?
> > >
> > > If you mean the runtime PM framework, then yes, I've been working on it.
> > >
> > > > Of course, the Android guys also want to pay attention to which apps
> > > > are running as well as to the state of devices on the system.
> > >
> > > In fact the runtime PM framework is also important to Android, because it
> > > can be used in there, for example, to implement the "early suspend" thing
> > > I referred to in one of my previous messages in this thread.
> >
> > Now we just need to convince the Android guys of that. ;-)
>
> I believe there's no need for that, as we were talking about that a few months
> ago.
Here is hoping...
Thanx, Paul
On Tuesday, August 03, 2010, Paul E. McKenney wrote:
> On Mon, Aug 02, 2010 at 11:33:32PM +0200, Rafael J. Wysocki wrote:
> > On Monday, August 02, 2010, Paul E. McKenney wrote:
> > > On Mon, Aug 02, 2010 at 03:52:20PM +0200, Rafael J. Wysocki wrote:
> > > > On Monday, August 02, 2010, Paul E. McKenney wrote:
> > > > > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> > > > > > On Sun, 1 Aug 2010 12:12:28 -0700
> > > > > > "Paul E. McKenney" <[email protected]> wrote:
> > > > ...
> > > > > > Another one: freezing whole cgroups..... we have that today. it
> > > > > > actually works quite well.... of course the hard part is the decision
> > > > > > what to put in which cgroup, and at what frequency and duration you let
> > > > > > cgroups run.
> > > > >
> > > > > Indeed, the Android guys seemed to be quite excited by cgroup freezing
> > > > > until they thought about the application-classification problem.
> > > > > Seems like it should be easy for some types of applications, but I do
> > > > > admit that apps can have non-trivial and non-obvious dependencies.
> > > >
> > > > This isn't more difficult than deciding which applications will be allowed to
> > > > use wakelocks (in the wakelocks world). It actually seems to be pretty much
> > > > equivalent to me. :-)
> > >
> > > If I understand correctly, the problem they were concerned about was
> > > instead "given that a certain set of apps are permitted to use wakelocks,
> > > which of the other apps can safely be frozen when the display blanks
> > > itself."
> >
> > I _think_ the problem should be reformulated as "which of the other apps
> > can be safely frozen without causing the wakelocks-using ones to have
> > problems" instead (the particular scenario is that one of the wakelocks-using
> > apps may need one of the other apps to process something and therefore the
> > other app cannot be frozen; however, that may be resolved by thawing all of
> > the other apps in such situations IMO).
>
> I agree that your statement is equivalent to mine. From what I can see,
> the current Android code resolves this by not freezing any app while
> a wakelock is held.
>
> Just out of curiosity, how are you detecting the situation in order to
> decide when to thaw the apps in the cgroup?
Well, in fact I would only be able to talk about that theoretically, as I'm
currently not involved in any project using cgroups for power management.
I have considered that, but I haven't tried to implement it.
Thanks,
Rafael
On Mon, 2 Aug 2010, Paul E. McKenney wrote:
> On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>>
>>> I'm a little worried that this whole "I need to block suspend" is
>>> temporary. Yes today there is silicon from ARM and Intel where suspend
>>> is a heavy operation, yet at the same time it's not all THAT heavy
>>> anymore.... at least on the Intel side it's good enough to use pretty
>>> much all the time (when the screen is off for now, but that's a memory
>>> controller issue more than anything else). I'm pretty sure the ARM guys
>>> will not be far behind.
>>
>> remember that this 'block suspend' is really 'block overriding the
>> fact that there are still runable processes and suspending anyway"
>>
>> having it labeled as 'suspend blocker' or even 'wakelock' makes it
>> sound as if it blocks any attempt to suspend, and I'm not sure
>> that's what's really intended. Itsounds like the normal syspend
>> process would continue to work, just this 'ignore if these other
>> apps are busy' mode of operation would not work.
>>
>> which makes me wonder, would it be possible to tell the normal idle
>> detection mechanism to ignore specific processes when deciding if it
>> should suspend or not? how about only considering processes in one
>> cgroup when deciding to suspend and ignoring all others?
>
> Why not flesh this out and compare it to the draft requirements?
> (I expect to be sending another version by end of day Pacific Time.)
>
> The biggest issue I see right off-hand is that a straightforward
> implementation of your idea would require moving processes from one
> cgroup to another when acquiring or releasing a suspend blocker, which
> from what I understand would be way to heavyweight. On the other hand,
> if acquiring and releasing a suspend blocker does not move the process
> from one cgroup to another, then you need something very like the
> suspend-blocker mechanism to handle those processes that are permitted
> to acquire suspend blockers, and which are thus not a member of the
> cgroup in question.
>
> That said, I did see some hint from the Android guys that it -might-
> be possible to leverage cgroups in the way that you suggest might help
> save power during times when suspend was blocked but (for example) the
> screen was turned off. The idea would be to freeze the cgroup whenever
> the screen blanked, even if suspend was blocked. The biggest issue
> here is that any process that can hold a suspend blocker must never to
> an unconditional wait on any process in this cgroup. Seems to me that
> this should be possible in theory, but the devil would be in the details.
>
> If I am misunderstanding your proposal, please enlighten me!
you are close, but I think what I'm proposing is actually simpler
(assuming that the scheduler can be configured to generate the appropriate
stats)
my thought was not to move applications between cgroups as they
aquire/release the suspend-block lock, bur rather to say that any
application that you would trust to get the suspend-block lock should be
in cgroup A while all other applications are in cgroup B
when you are deciding if the system shoudl go to sleep because it is idle,
ignore the activity of all applications in cgroup B
if cgroup A applications are busy, the system is not idle and should not
suspend.
this requires that the applications in cgroup A actually go idle as
opposed to simply releaseing the suspend-block lock, but it would mean
that there are no application changes required for to move a system from
the status "even if it's busy, go ahead ans suspend" to "this application
is important, don't suspend if it's got work to do", it would just be
classifying the application in one cgroup or the other.
This assumes that an application that you would trust to hold the
suspend-block lock is going to be well behaved (if it isn't, how can you
trust it to not grab the lock inappropriatly?)
David Lang
On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>
>> On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
>>>
>>> On Sun, 1 Aug 2010, Arjan van de Ven wrote:
>>>
>>>> I'm a little worried that this whole "I need to block suspend" is
>>>> temporary. Yes today there is silicon from ARM and Intel where suspend
>>>> is a heavy operation, yet at the same time it's not all THAT heavy
>>>> anymore.... at least on the Intel side it's good enough to use pretty
>>>> much all the time (when the screen is off for now, but that's a memory
>>>> controller issue more than anything else). I'm pretty sure the ARM guys
>>>> will not be far behind.
>>>
>>> remember that this 'block suspend' is really 'block overriding the
>>> fact that there are still runable processes and suspending anyway"
>>>
>>> having it labeled as 'suspend blocker' or even 'wakelock' makes it
>>> sound as if it blocks any attempt to suspend, and I'm not sure
>>> that's what's really intended. Itsounds like the normal syspend
>>> process would continue to work, just this 'ignore if these other
>>> apps are busy' mode of operation would not work.
>>>
>>> which makes me wonder, would it be possible to tell the normal idle
>>> detection mechanism to ignore specific processes when deciding if it
>>> should suspend or not? how about only considering processes in one
>>> cgroup when deciding to suspend and ignoring all others?
>>
>> Why not flesh this out and compare it to the draft requirements?
>> (I expect to be sending another version by end of day Pacific Time.)
>>
>> The biggest issue I see right off-hand is that a straightforward
>> implementation of your idea would require moving processes from one
>> cgroup to another when acquiring or releasing a suspend blocker, which
>> from what I understand would be way to heavyweight. ?On the other hand,
>> if acquiring and releasing a suspend blocker does not move the process
>> from one cgroup to another, then you need something very like the
>> suspend-blocker mechanism to handle those processes that are permitted
>> to acquire suspend blockers, and which are thus not a member of the
>> cgroup in question.
>>
>> That said, I did see some hint from the Android guys that it -might-
>> be possible to leverage cgroups in the way that you suggest might help
>> save power during times when suspend was blocked but (for example) the
>> screen was turned off. ?The idea would be to freeze the cgroup whenever
>> the screen blanked, even if suspend was blocked. ?The biggest issue
>> here is that any process that can hold a suspend blocker must never to
>> an unconditional wait on any process in this cgroup. ?Seems to me that
>> this should be possible in theory, but the devil would be in the details.
>>
>> If I am misunderstanding your proposal, please enlighten me!
>
> you are close, but I think what I'm proposing is actually simpler (assuming
> that the scheduler can be configured to generate the appropriate stats)
>
> my thought was not to move applications between cgroups as they
> aquire/release the suspend-block lock, bur rather to say that any
> application that you would trust to get the suspend-block lock should be in
> cgroup A while all other applications are in cgroup B
>
> when you are deciding if the system shoudl go to sleep because it is idle,
> ignore the activity of all applications in cgroup B
>
> if cgroup A applications are busy, the system is not idle and should not
> suspend.
>
Triggering suspend from idle has been suggested before. However, idle
is not a signal that it is safe to suspend since timers stop in
suspend (or the code could temporarily be waiting on a non-wakeup
interrupt). If you add suspend blockers or wakelocks to prevent
suspend while events you care about are pending, then it does not make
a lot of sense to prevent suspend just because the cpu is not idle.
> this requires that the applications in cgroup A actually go idle as opposed
> to simply releaseing the suspend-block lock, but it would mean that there
> are no application changes required for to move a system from the status
> "even if it's busy, go ahead ans suspend" to "this application is important,
> don't suspend if it's got work to do", it would just be classifying the
> application in one cgroup or the other.
>
> This assumes that an application that you would trust to hold the
> suspend-block lock is going to be well behaved (if it isn't, how can you
> trust it to not grab the lock inappropriatly?)
>
> David Lang
>
--
Arve Hj?nnev?g
On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
<[email protected]> wrote:
...
> 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.
>
The problem with using open and close to prevent an allow suspend is
not that it is too slow but that it interferes with collecting stats.
The wakelock code has a sysfs interface that allow you to use a
open/write/close sequence to block or unblock suspend. There is no
limit to the amount of kernel memory that a process can consume with
this interface, so the suspend blocker patchset uses a /dev interface
with ioctls to block or unblock suspend and it destroys the kernel
object when the file descriptor is closed.
> 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.
>
We don't key the stats off the program name, but having useful
statistics is critical too us. The current code in linux-next does not
appear to allow this (I'm referring to pm_stay_awake here, etc not
pm-qos.)
> 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.)
wake-lock/suspend-blocker timeouts have nothing to do with the timeout
used by applications when waiting for a response from a less trusted
application.
>
> 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.)
I would say it should suspend even if power aware applications are
runnable. Most applications do not exclusively perform critical work.
>
> 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.
>
It must be power-efficient. Repeated attempts to suspend will kill the
idle battery life.
> 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.)
>
Unconditional initialization makes it easier to add suspend blockers
to existing kernel code since you don't have to add new failure exit
paths. It is not a strong requirement.
> 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.
>
>
--
Arve Hj?nnev?g
On Sun, Aug 1, 2010 at 11:53 PM, Florian Mickler <[email protected]> wrote:
>
> Thinking about it.. I don't know much about cgroups, but I think a
> process can only be in one cgroup at a time.
A thread can only be in one cgroup in each hierarchy at one time. You
can mount multiple cgroups hierarchies, with different resource
controllers on different hierarchies.
>
> b) you can't use cgroup for other purposes anymore. I.e. if you want to
> have 2 groups that each only have half of the memory available, how
> would you then integrate the cgroup-ignore-for-idle-approach with this?
You could mount the subsystem that provides the "ignore-for-idle"
support on one hierarchy, and partition the trusted/untrusted
processes that way, and the memory controller subsystem on a different
hierarchy, with whatever split you wanted for memory controls.
Paul
On Mon, Aug 2, 2010 at 2:06 AM, <[email protected]> wrote:
>
> yes, it could mean a doubleing in the number of cgroups that you need on a
> system. and if there are other features like this you can end up in a
> geometric explosion in the number of cgroups.
No, it would be additive - you can mount different subsystems on
separate hierarchies. So if you had X divisions for memory, Y
divisions for CPU and Z divisions for suspend-blocking (where Z=2,
probably?) you could mount three separate hierarchies and have X+Y+Z
complexity, not X*Y*Z.
(Not that I have a strong opinion on whether cgroups is an appropriate
mechanism for solving this problem - just that the problem you forsee
shouldn't occur in practice).
Paul
On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
> On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>
>>
>> you are close, but I think what I'm proposing is actually simpler (assuming
>> that the scheduler can be configured to generate the appropriate stats)
>>
>> my thought was not to move applications between cgroups as they
>> aquire/release the suspend-block lock, bur rather to say that any
>> application that you would trust to get the suspend-block lock should be in
>> cgroup A while all other applications are in cgroup B
>>
>> when you are deciding if the system shoudl go to sleep because it is idle,
>> ignore the activity of all applications in cgroup B
>>
>> if cgroup A applications are busy, the system is not idle and should not
>> suspend.
>>
>
> Triggering suspend from idle has been suggested before. However, idle
> is not a signal that it is safe to suspend since timers stop in
> suspend (or the code could temporarily be waiting on a non-wakeup
> interrupt). If you add suspend blockers or wakelocks to prevent
> suspend while events you care about are pending, then it does not make
> a lot of sense to prevent suspend just because the cpu is not idle.
isn't this a matter of making the suspend decision look at what timers
have been set to expire in the near future and/or tweaking how long the
system needs to be idle before going to sleep?
to properly do a good job at suspending hyperagressivly you need to look
at when you need to wake back up (after all, if you are only going to
sleep for 1 second, it makes no sense to try and enter a sleep state that
takes .5 seconds to get into and .6 seconds to get out of, you need to
pick a lighter power saving mode)
if you really want to have the application be able to say 'I am ready for
you to go to sleep NOW and I don't want any chance of waking back up until
the system is ready for me to do so' it may be possible to have a special
dev file that when a program attempts to read from it the program is
considered to have been idle forever (expiring any 'delay since last
activity' timers that are running for that process) and when the device
wakes back up (or after a little bit of time if the device decides not to
go back to sleep), allow the return from the blocking call to allow the
app to continue running.
but I am not sure that something like that is needed. I think just
checking for timers that are due to expire 'soon' and tweaking how long
the system must be 'idle' before it decides to go to sleep should be good
enough.
David Lang
On Sun, Aug 1, 2010 at 6:10 PM, Paul E. McKenney
<[email protected]> wrote:
> On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
...
>> Another one: freezing whole cgroups..... we have that today. it
>> actually works quite well.... of course the hard part is the decision
>> what to put in which cgroup, and at what frequency and duration you let
>> cgroups run.
>
> Indeed, the Android guys seemed to be quite excited by cgroup freezing
> until they thought about the application-classification problem.
> Seems like it should be easy for some types of applications, but I do
> admit that apps can have non-trivial and non-obvious dependencies.
>
The dependencies is what made this solution uninteresting to us. For
instance, we currently use cgroup scheduling to reduce the impact of
some background tasks, but we occasionally saw a watchdog restart of
the system process were critical services were waiting on a kernel
mutex owned by a background task for more than 20 seconds. If we froze
a cgroup instead, we would not hit this particular problem since tasks
cannot be frozen while executing kernel code the same way they can be
preempted, but nothing prevents a task from being frozen while holding
a user-space resource.
--
Arve Hj?nnev?g
2010/8/2 <[email protected]>:
> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>
>> On Mon, Aug 2, 2010 at 5:08 PM, ?<[email protected]> wrote:
>>>
>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>>
>>>
>>> you are close, but I think what I'm proposing is actually simpler
>>> (assuming
>>> that the scheduler can be configured to generate the appropriate stats)
>>>
>>> my thought was not to move applications between cgroups as they
>>> aquire/release the suspend-block lock, bur rather to say that any
>>> application that you would trust to get the suspend-block lock should be
>>> in
>>> cgroup A while all other applications are in cgroup B
>>>
>>> when you are deciding if the system shoudl go to sleep because it is
>>> idle,
>>> ignore the activity of all applications in cgroup B
>>>
>>> if cgroup A applications are busy, the system is not idle and should not
>>> suspend.
>>>
>>
>> Triggering suspend from idle has been suggested before. However, idle
>> is not a signal that it is safe to suspend since timers stop in
>> suspend (or the code could temporarily be waiting on a non-wakeup
>> interrupt). If you add suspend blockers or wakelocks to prevent
>> suspend while events you care about are pending, then it does not make
>> a lot of sense to prevent suspend just because the cpu is not idle.
>
> isn't this a matter of making the suspend decision look at what timers have
> been set to expire in the near future and/or tweaking how long the system
> needs to be idle before going to sleep?
>
You are describing low power idle modes, not suspend. Most timers stop
in suspend, so a timer set 10 seconds from now when entering suspend
will go off 10 seconds after resume so it should have no impact on how
long you decide to stay in suspend.
> to properly do a good job at suspending hyperagressivly you need to look at
> when you need to wake back up (after all, if you are only going to sleep for
> 1 second, it makes no sense to try and enter a sleep state that takes .5
> seconds to get into and .6 seconds to get out of, you need to pick a lighter
> power saving mode)
>
> if you really want to have the application be able to say 'I am ready for
> you to go to sleep NOW and I don't want any chance of waking back up until
> the system is ready for me to do so' it may be possible to have a special
> dev file that when a program attempts to read from it the program is
> considered to have been idle forever (expiring any 'delay since last
> activity' timers that are running for that process) and when the device
> wakes back up (or after a little bit of time if the device decides not to go
> back to sleep), allow the return from the blocking call to allow the app to
> continue running.
>
> but I am not sure that something like that is needed. I think just checking
> for timers that are due to expire 'soon' and tweaking how long the system
> must be 'idle' before it decides to go to sleep should be good enough.
>
> David Lang
>
--
Arve Hj?nnev?g
On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/2 <[email protected]>:
>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> On Mon, Aug 2, 2010 at 5:08 PM, ?<[email protected]> wrote:
>>>>
>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>
>>>> you are close, but I think what I'm proposing is actually simpler
>>>> (assuming
>>>> that the scheduler can be configured to generate the appropriate stats)
>>>>
>>>> my thought was not to move applications between cgroups as they
>>>> aquire/release the suspend-block lock, bur rather to say that any
>>>> application that you would trust to get the suspend-block lock should be
>>>> in
>>>> cgroup A while all other applications are in cgroup B
>>>>
>>>> when you are deciding if the system shoudl go to sleep because it is
>>>> idle,
>>>> ignore the activity of all applications in cgroup B
>>>>
>>>> if cgroup A applications are busy, the system is not idle and should not
>>>> suspend.
>>>>
>>>
>>> Triggering suspend from idle has been suggested before. However, idle
>>> is not a signal that it is safe to suspend since timers stop in
>>> suspend (or the code could temporarily be waiting on a non-wakeup
>>> interrupt). If you add suspend blockers or wakelocks to prevent
>>> suspend while events you care about are pending, then it does not make
>>> a lot of sense to prevent suspend just because the cpu is not idle.
>>
>> isn't this a matter of making the suspend decision look at what timers have
>> been set to expire in the near future and/or tweaking how long the system
>> needs to be idle before going to sleep?
>>
>
> You are describing low power idle modes, not suspend. Most timers stop
> in suspend, so a timer set 10 seconds from now when entering suspend
> will go off 10 seconds after resume so it should have no impact on how
> long you decide to stay in suspend.
so what is the fundamental difference between deciding to go into
low-power idle modes to wake up back up on a given point in the future and
deciding that you are going to be idle for so long that you may as well
suspend until there is user input?
David Lang
Hi!
On Mon, 2 Aug 2010 21:38:12 -0700
Paul Menage <[email protected]> wrote:
> On Sun, Aug 1, 2010 at 11:53 PM, Florian Mickler <[email protected]> wrote:
> >
> > Thinking about it.. I don't know much about cgroups, but I think a
> > process can only be in one cgroup at a time.
>
> A thread can only be in one cgroup in each hierarchy at one time. You
> can mount multiple cgroups hierarchies, with different resource
> controllers on different hierarchies.
>
> >
> > b) you can't use cgroup for other purposes anymore. I.e. if you want to
> > have 2 groups that each only have half of the memory available, how
> > would you then integrate the cgroup-ignore-for-idle-approach with this?
>
> You could mount the subsystem that provides the "ignore-for-idle"
> support on one hierarchy, and partition the trusted/untrusted
> processes that way, and the memory controller subsystem on a different
> hierarchy, with whatever split you wanted for memory controls.
>
> Paul
Thank you for the clarification. That renders my original objections
more or less void.
I've still got some doubts about the flexibility of this approach (think
an open system with arbitrary software components). But with a userspace
manager that sorts processes into the groups this may be a possible
solution.
But we should probably concentrate first on the requirements now. If we
have a set of requirements everyone can agree too, we may be on our way
to get a solution.
Cheers,
Flo
On Mon, 2 Aug 2010 21:41:17 -0700
Paul Menage <[email protected]> wrote:
> On Mon, Aug 2, 2010 at 2:06 AM, <[email protected]> wrote:
> >
> > yes, it could mean a doubleing in the number of cgroups that you need on a
> > system. and if there are other features like this you can end up in a
> > geometric explosion in the number of cgroups.
>
> No, it would be additive - you can mount different subsystems on
> separate hierarchies. So if you had X divisions for memory, Y
> divisions for CPU and Z divisions for suspend-blocking (where Z=2,
> probably?) you could mount three separate hierarchies and have X+Y+Z
> complexity, not X*Y*Z.
>
> (Not that I have a strong opinion on whether cgroups is an appropriate
> mechanism for solving this problem - just that the problem you forsee
> shouldn't occur in practice).
>
> Paul
Ah yes, mea culpa. I've got this wrong.
Cheers,
Flo
On Mon, Aug 02, 2010 at 09:56:10PM -0700, Arve Hj?nnev?g wrote:
> On Sun, Aug 1, 2010 at 6:10 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Sun, Aug 01, 2010 at 03:47:08PM -0700, Arjan van de Ven wrote:
> ...
> >> Another one: freezing whole cgroups..... we have that today. it
> >> actually works quite well.... of course the hard part is the decision
> >> what to put in which cgroup, and at what frequency and duration you let
> >> cgroups run.
> >
> > Indeed, the Android guys seemed to be quite excited by cgroup freezing
> > until they thought about the application-classification problem.
> > Seems like it should be easy for some types of applications, but I do
> > admit that apps can have non-trivial and non-obvious dependencies.
>
> The dependencies is what made this solution uninteresting to us. For
> instance, we currently use cgroup scheduling to reduce the impact of
> some background tasks, but we occasionally saw a watchdog restart of
> the system process were critical services were waiting on a kernel
> mutex owned by a background task for more than 20 seconds. If we froze
> a cgroup instead, we would not hit this particular problem since tasks
> cannot be frozen while executing kernel code the same way they can be
> preempted, but nothing prevents a task from being frozen while holding
> a user-space resource.
Excellent point -- I had completely missed this failure mode!!!
Thanx, Paul
On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hj?nnev?g wrote:
> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
> <[email protected]> wrote:
> ...
First, thank you very much for your review and feedback!
> > 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.
>
> The problem with using open and close to prevent an allow suspend is
> not that it is too slow but that it interferes with collecting stats.
> The wakelock code has a sysfs interface that allow you to use a
> open/write/close sequence to block or unblock suspend. There is no
> limit to the amount of kernel memory that a process can consume with
> this interface, so the suspend blocker patchset uses a /dev interface
> with ioctls to block or unblock suspend and it destroys the kernel
> object when the file descriptor is closed.
Ah, I missed this point. What I am doing to adjust is to strike the
above requirement, and to add verbiage to the "statistics" requirement
about using ioctl() to implement suspend-blocker operations, so that the
statistics can be tracked based on the device being open throughout the
application's lifetime.
> > 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.
>
> We don't key the stats off the program name, but having useful
> statistics is critical too us. The current code in linux-next does not
> appear to allow this (I'm referring to pm_stay_awake here, etc not
> pm-qos.)
OK, maybe I was confused earlier. So you do not track statistics via
the device being open throughout the application's lifetime?
I am not familiar with pm_stay_awake(), but will take a look at it.
> > 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.)
>
> wake-lock/suspend-blocker timeouts have nothing to do with the timeout
> used by applications when waiting for a response from a less trusted
> application.
OK, I moved this to a new "SUGGESTED USAGE" section and removed the
last (parenthesized) sentence.
> > 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.)
>
> I would say it should suspend even if power aware applications are
> runnable. Most applications do not exclusively perform critical work.
The point being that a power-aware application does not block suspend
-unless- it holds a suspend blocker, correct?
Or am I missing some other subtlety?
> > 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.
>
> It must be power-efficient. Repeated attempts to suspend will kill the
> idle battery life.
Good point! I changed "Transition to low-power state must be efficient"
to instead read "Transition to low-power state must be power-efficient."
> > 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.)
>
> Unconditional initialization makes it easier to add suspend blockers
> to existing kernel code since you don't have to add new failure exit
> paths. It is not a strong requirement.
Ah, that makes more sense! I moved this to a new "NICE-TO-HAVES"
section. I also changed the last parenthesized sentence to read
"Such unconditional initialization reduces the intrusiveness of the
the Android patchset." Does that work?
> > 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.
Thank you again for looking this over and for your comments!!!
Thanx, Paul
On Mon, 2010-08-02 at 21:18 -0700, Arve Hjønnevåg wrote:
> > 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.
> >
>
> The problem with using open and close to prevent an allow suspend is
> not that it is too slow but that it interferes with collecting stats.
Please elaborate on this. I expect the pm-qos stats interface will
collect stats across user open/close because that's how it currently
works. What's the problem?
> The wakelock code has a sysfs interface that allow you to use a
> open/write/close sequence to block or unblock suspend. There is no
> limit to the amount of kernel memory that a process can consume with
> this interface, so the suspend blocker patchset uses a /dev interface
> with ioctls to block or unblock suspend and it destroys the kernel
> object when the file descriptor is closed.
This is an implementation detail only. The pm-qos objects are long
lived, so their stats would be too. I would guess that explicit stat
clearing might be a useful option.
James
2010/8/3 James Bottomley <[email protected]>:
> On Mon, 2010-08-02 at 21:18 -0700, Arve Hj?nnev?g wrote:
>> > 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.
>> >
>>
>> The problem with using open and close to prevent an allow suspend is
>> not that it is too slow but that it interferes with collecting stats.
>
> Please elaborate on this. ?I expect the pm-qos stats interface will
> collect stats across user open/close because that's how it currently
> works. ?What's the problem?
>
The pm-qos interface creates the request object in open and destroys
it in release just like the suspend blocker interface. We need stats
for each client which is lost if you free the object every time you
unblock suspend.
Or are you talking about user space opening and closing the stats
interface (which does not cause any problems)?
>> The wakelock code has a sysfs interface that allow you to use a
>> open/write/close sequence to block or unblock suspend. There is no
>> limit to the amount of kernel memory that a process can consume with
>> this interface, so the suspend blocker patchset uses a /dev interface
>> with ioctls to block or unblock suspend and it destroys the kernel
>> object when the file descriptor is closed.
>
> This is an implementation detail only.
There is no way fix it without changing the user space visible
behavior of the API. The kernel does not know when it is safe to free
the objects.
>?The pm-qos objects are long
> lived, so their stats would be too. ?I would guess that explicit stat
> clearing might be a useful option.
>
Which pm-qos objects are you referring to? The struct pm_qos_object
that backs each pm-qos class is long lived (I don't know why this is
named pm_qos_object), but we need stats in struct pm_qos_request_list.
--
Arve Hj?nnev?g
2010/8/3 Paul E. McKenney <[email protected]>:
> On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hj?nnev?g wrote:
>> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
>> <[email protected]> wrote:
...
>> > o ? ? ? Statistics of the power-control actions taken by power-aware
>> > ? ? ? ?applications must be provided, and must be keyed off of program
>> > ? ? ? ?name.
>>
>> We don't key the stats off the program name, but having useful
>> statistics is critical too us. The current code in linux-next does not
>> appear to allow this (I'm referring to pm_stay_awake here, etc not
>> pm-qos.)
>
> OK, maybe I was confused earlier. ?So you do not track statistics via
> the device being open throughout the application's lifetime?
>
The suspend blocker patchset does track statistics while the device is
open, but it it not keyed of the program name. The name is passed from
user-space and a single process can have the device open several
times. The wakelock interface that we currently use just creates a new
object every time it sees a new name and never frees it.
...
>> > 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.)
>>
>> I would say it should suspend even if power aware applications are
>> runnable. Most applications do not exclusively perform critical work.
>
> The point being that a power-aware application does not block suspend
> -unless- it holds a suspend blocker, correct?
Yes.
>
> Or am I missing some other subtlety?
No.
...
>> > 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.)
>>
>> Unconditional initialization makes it easier to add suspend blockers
>> to existing kernel code since you don't have to add new failure exit
>> paths. It is not a strong requirement.
>
> Ah, that makes more sense! ?I moved this to a new "NICE-TO-HAVES"
> section. ?I also changed the last parenthesized sentence to read
> "Such unconditional initialization reduces the intrusiveness of the
> the Android patchset." ?Does that work?
>
Sure.
--
Arve Hj?nnev?g
2010/8/2 <[email protected]>:
> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/2 ?<[email protected]>:
>>>
>>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>>>
>>>> On Mon, Aug 2, 2010 at 5:08 PM, ?<[email protected]> wrote:
>>>>>
>>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>>
>>>>> you are close, but I think what I'm proposing is actually simpler
>>>>> (assuming
>>>>> that the scheduler can be configured to generate the appropriate stats)
>>>>>
>>>>> my thought was not to move applications between cgroups as they
>>>>> aquire/release the suspend-block lock, bur rather to say that any
>>>>> application that you would trust to get the suspend-block lock should
>>>>> be
>>>>> in
>>>>> cgroup A while all other applications are in cgroup B
>>>>>
>>>>> when you are deciding if the system shoudl go to sleep because it is
>>>>> idle,
>>>>> ignore the activity of all applications in cgroup B
>>>>>
>>>>> if cgroup A applications are busy, the system is not idle and should
>>>>> not
>>>>> suspend.
>>>>>
>>>>
>>>> Triggering suspend from idle has been suggested before. However, idle
>>>> is not a signal that it is safe to suspend since timers stop in
>>>> suspend (or the code could temporarily be waiting on a non-wakeup
>>>> interrupt). If you add suspend blockers or wakelocks to prevent
>>>> suspend while events you care about are pending, then it does not make
>>>> a lot of sense to prevent suspend just because the cpu is not idle.
>>>
>>> isn't this a matter of making the suspend decision look at what timers
>>> have
>>> been set to expire in the near future and/or tweaking how long the system
>>> needs to be idle before going to sleep?
>>>
>>
>> You are describing low power idle modes, not suspend. Most timers stop
>> in suspend, so a timer set 10 seconds from now when entering suspend
>> will go off 10 seconds after resume so it should have no impact on how
>> long you decide to stay in suspend.
>
> so what is the fundamental difference between deciding to go into low-power
> idle modes to wake up back up on a given point in the future and deciding
> that you are going to be idle for so long that you may as well suspend until
> there is user input?
>
Low power idle modes are supposed to be transparent. Suspend stops the
monotonic clock, ignores ready threads and switches over to a separate
set of wakeup events/interrupts. We don't suspend until there is user
input, we suspend until there is a wakeup event (user-input, incoming
network data/phone-calls, alarms etc..).
--
Arve Hj?nnev?g
On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/2 <[email protected]>:
>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/2 ?<[email protected]>:
>>>>
>>>> On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>> On Mon, Aug 2, 2010 at 5:08 PM, ?<[email protected]> wrote:
>>>>>>
>>>>>> On Mon, 2 Aug 2010, Paul E. McKenney wrote:
>>>>>>
>>>>>>
>>>>>> you are close, but I think what I'm proposing is actually simpler
>>>>>> (assuming
>>>>>> that the scheduler can be configured to generate the appropriate stats)
>>>>>>
>>>>>> my thought was not to move applications between cgroups as they
>>>>>> aquire/release the suspend-block lock, bur rather to say that any
>>>>>> application that you would trust to get the suspend-block lock should
>>>>>> be
>>>>>> in
>>>>>> cgroup A while all other applications are in cgroup B
>>>>>>
>>>>>> when you are deciding if the system shoudl go to sleep because it is
>>>>>> idle,
>>>>>> ignore the activity of all applications in cgroup B
>>>>>>
>>>>>> if cgroup A applications are busy, the system is not idle and should
>>>>>> not
>>>>>> suspend.
>>>>>>
>>>>>
>>>>> Triggering suspend from idle has been suggested before. However, idle
>>>>> is not a signal that it is safe to suspend since timers stop in
>>>>> suspend (or the code could temporarily be waiting on a non-wakeup
>>>>> interrupt). If you add suspend blockers or wakelocks to prevent
>>>>> suspend while events you care about are pending, then it does not make
>>>>> a lot of sense to prevent suspend just because the cpu is not idle.
>>>>
>>>> isn't this a matter of making the suspend decision look at what timers
>>>> have
>>>> been set to expire in the near future and/or tweaking how long the system
>>>> needs to be idle before going to sleep?
>>>>
>>>
>>> You are describing low power idle modes, not suspend. Most timers stop
>>> in suspend, so a timer set 10 seconds from now when entering suspend
>>> will go off 10 seconds after resume so it should have no impact on how
>>> long you decide to stay in suspend.
>>
>> so what is the fundamental difference between deciding to go into low-power
>> idle modes to wake up back up on a given point in the future and deciding
>> that you are going to be idle for so long that you may as well suspend until
>> there is user input?
>>
>
> Low power idle modes are supposed to be transparent. Suspend stops the
> monotonic clock, ignores ready threads and switches over to a separate
> set of wakeup events/interrupts. We don't suspend until there is user
> input, we suspend until there is a wakeup event (user-input, incoming
> network data/phone-calls, alarms etc..).
s/user input/wakeup event/ and my question still stands.
low power modes are not transparent to the user in all cases (if the
screen backlight dimms/shuts off a user reading something will notice, if
the system switches to a lower clock speed it can impact user response
time, etc) The system is making it's best guess as to how to best srve the
user by sacraficing some capibilities to save power now so that the power
can be available later.
as I see it, suspending until a wakeup event (button press, incoming call,
alarm, etc) is just another datapoint along the same path.
If the system could not wake itself up to respond to user input, phone
call, alarm, etc and needed the power button pressed to wake up (or shut
down to the point where the battery could be removed and reinstalled a
long time later), I would see things moving into a different category, but
as long as the system has the ability to wake itself up later (and is
still consuming power) I see the suspend as being in the same category as
the other low-power modes (it's just more expensive to go in and out of)
why should the suspend be put into a different category from the other
low-power states?
David Lang
On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>
> >2010/8/2 <[email protected]>:
> >>On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>>2010/8/2 ?<[email protected]>:
> >>>>
> >>>>On Mon, 2 Aug 2010, Arve Hj?nnev?g wrote:
> >>>>
> >>>>>On Mon, Aug 2, 2010 at 5:08 PM, ?<[email protected]> wrote:
> >>>>>>
> >>>>>>On Mon, 2 Aug 2010, Paul E. McKenney wrote:
> >>>>>>
> >>>>>>
> >>>>>>you are close, but I think what I'm proposing is actually simpler
> >>>>>>(assuming
> >>>>>>that the scheduler can be configured to generate the appropriate stats)
> >>>>>>
> >>>>>>my thought was not to move applications between cgroups as they
> >>>>>>aquire/release the suspend-block lock, bur rather to say that any
> >>>>>>application that you would trust to get the suspend-block lock should
> >>>>>>be
> >>>>>>in
> >>>>>>cgroup A while all other applications are in cgroup B
> >>>>>>
> >>>>>>when you are deciding if the system shoudl go to sleep because it is
> >>>>>>idle,
> >>>>>>ignore the activity of all applications in cgroup B
> >>>>>>
> >>>>>>if cgroup A applications are busy, the system is not idle and should
> >>>>>>not
> >>>>>>suspend.
> >>>>>>
> >>>>>
> >>>>>Triggering suspend from idle has been suggested before. However, idle
> >>>>>is not a signal that it is safe to suspend since timers stop in
> >>>>>suspend (or the code could temporarily be waiting on a non-wakeup
> >>>>>interrupt). If you add suspend blockers or wakelocks to prevent
> >>>>>suspend while events you care about are pending, then it does not make
> >>>>>a lot of sense to prevent suspend just because the cpu is not idle.
> >>>>
> >>>>isn't this a matter of making the suspend decision look at what timers
> >>>>have
> >>>>been set to expire in the near future and/or tweaking how long the system
> >>>>needs to be idle before going to sleep?
> >>>>
> >>>
> >>>You are describing low power idle modes, not suspend. Most timers stop
> >>>in suspend, so a timer set 10 seconds from now when entering suspend
> >>>will go off 10 seconds after resume so it should have no impact on how
> >>>long you decide to stay in suspend.
> >>
> >>so what is the fundamental difference between deciding to go into low-power
> >>idle modes to wake up back up on a given point in the future and deciding
> >>that you are going to be idle for so long that you may as well suspend until
> >>there is user input?
> >>
> >
> >Low power idle modes are supposed to be transparent. Suspend stops the
> >monotonic clock, ignores ready threads and switches over to a separate
> >set of wakeup events/interrupts. We don't suspend until there is user
> >input, we suspend until there is a wakeup event (user-input, incoming
> >network data/phone-calls, alarms etc..).
>
> s/user input/wakeup event/ and my question still stands.
>
> low power modes are not transparent to the user in all cases (if the
> screen backlight dimms/shuts off a user reading something will
> notice, if the system switches to a lower clock speed it can impact
> user response time, etc) The system is making it's best guess as to
> how to best srve the user by sacraficing some capibilities to save
> power now so that the power can be available later.
>
> as I see it, suspending until a wakeup event (button press, incoming
> call, alarm, etc) is just another datapoint along the same path.
>
> If the system could not wake itself up to respond to user input,
> phone call, alarm, etc and needed the power button pressed to wake
> up (or shut down to the point where the battery could be removed and
> reinstalled a long time later), I would see things moving into a
> different category, but as long as the system has the ability to
> wake itself up later (and is still consuming power) I see the
> suspend as being in the same category as the other low-power modes
> (it's just more expensive to go in and out of)
>
>
> why should the suspend be put into a different category from the
> other low-power states?
OK, I'll bite...
>From an Android perspective, the differences are as follows:
1. Deep idle states are entered only if there are no runnable tasks.
In contrast, opportunistic suspend can happen even when there
are tasks that are ready, willing, and able to run.
2. There can be a set of input events that do not bring the system
out of suspend, but which would bring the system out of a deep
idle state. For example, I believe that it was stated that one
of the Android-based smartphones ignores touchscreen input while
suspended, but pays attention to it while in deep idle states.
3. The system comes out of a deep idle state when a timer
expires. In contrast, timers cannot expire while the
system is suspended. (This one is debatable: some people
argue that timers are subject to jitter, and the suspend
case for timers is the same as that for deep idle states,
but with unbounded timer jitter. Others disagree. The
resulting discussions have produced much heat, but little
light. Such is life.)
There may well be others.
Whether these distinctions are a good thing or a bad thing is one of
the topics of this discussion. But the distinctions themselves are
certainly very real, from what I can see.
Or am I missing your point?
Thanx, Paul
On Tue, 3 Aug 2010, Paul E. McKenney wrote:
> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/2 <[email protected]>:
>>>>
>>>> so what is the fundamental difference between deciding to go into low-power
>>>> idle modes to wake up back up on a given point in the future and deciding
>>>> that you are going to be idle for so long that you may as well suspend until
>>>> there is user input?
>>>>
>>>
>>> Low power idle modes are supposed to be transparent. Suspend stops the
>>> monotonic clock, ignores ready threads and switches over to a separate
>>> set of wakeup events/interrupts. We don't suspend until there is user
>>> input, we suspend until there is a wakeup event (user-input, incoming
>>> network data/phone-calls, alarms etc..).
>>
>> s/user input/wakeup event/ and my question still stands.
>>
>> low power modes are not transparent to the user in all cases (if the
>> screen backlight dimms/shuts off a user reading something will
>> notice, if the system switches to a lower clock speed it can impact
>> user response time, etc) The system is making it's best guess as to
>> how to best srve the user by sacraficing some capibilities to save
>> power now so that the power can be available later.
>>
>> as I see it, suspending until a wakeup event (button press, incoming
>> call, alarm, etc) is just another datapoint along the same path.
>>
>> If the system could not wake itself up to respond to user input,
>> phone call, alarm, etc and needed the power button pressed to wake
>> up (or shut down to the point where the battery could be removed and
>> reinstalled a long time later), I would see things moving into a
>> different category, but as long as the system has the ability to
>> wake itself up later (and is still consuming power) I see the
>> suspend as being in the same category as the other low-power modes
>> (it's just more expensive to go in and out of)
>>
>>
>> why should the suspend be put into a different category from the
>> other low-power states?
>
> OK, I'll bite...
thanks, this is not intended to be a trap.
> From an Android perspective, the differences are as follows:
>
> 1. Deep idle states are entered only if there are no runnable tasks.
> In contrast, opportunistic suspend can happen even when there
> are tasks that are ready, willing, and able to run.
Ok, this is a complication to what I'm proposing (and seems a little odd,
but I can see how it can work), but not neccessarily a major problem. it
depends on exactly how the decision is made to go into low power states
and/or suspend. If this is done by an application that is able to look at
either all activity or ignore one cgroup of processes at different times
in it's calculations than this would work.
> 2. There can be a set of input events that do not bring the system
> out of suspend, but which would bring the system out of a deep
> idle state. For example, I believe that it was stated that one
> of the Android-based smartphones ignores touchscreen input while
> suspended, but pays attention to it while in deep idle states.
I see this as simply being a matter of what devices are still enabled at
the different power savings levels. At one level the touchscreen is still
powered, while at another level it isn't, and at yet another level you have
to hit the power soft-button. This isn't fundamentally different from
powering off a USB peripheral that the system decides is idle (and then
not seeing input from it until something else wakes the system)
> 3. The system comes out of a deep idle state when a timer
> expires. In contrast, timers cannot expire while the
> system is suspended. (This one is debatable: some people
> argue that timers are subject to jitter, and the suspend
> case for timers is the same as that for deep idle states,
> but with unbounded timer jitter. Others disagree. The
> resulting discussions have produced much heat, but little
> light. Such is life.)
if you have the ability to wake for an alarm, you have the ability to wake
for a timer (if from no other method than to set the alarm to when the
timer tick would go off)
> There may well be others.
>
> Whether these distinctions are a good thing or a bad thing is one of
> the topics of this discussion. But the distinctions themselves are
> certainly very real, from what I can see.
>
> Or am I missing your point?
these big distinction that I see as significant seem to be in the decision
of when to go into the different states, and the difference between the
states themselves seem to be less significant (and either very close to,
or within the variation that already exists for power saving modes)
If I'm right bout this, then it would seem to simplify the concept and
change it from some really foreign android-only thing into a special case
variation of existing core concepts.
you have many different power saving modes, the daemon (or kernel code)
that is determining which mode to go into would need different logic
(including, but not limited to the ability to be able to ignore one or
more cgroups of processes). different power saving modes have different
trade-offs, and some of them power down different peripherals (which is
always a platform specific, if not system specific set of trade-offs)
This all depends on the ability for the code that decides to switch power
modes (including to trigger suspend) to be able to see things in
sufficient detail to be able to do different things depending on the class
of programs. I don't know enough about this code to know if this is the
case or not, I really wish that someone familiar with the power saving
code could either confirm that this is possible, or state that it's not
possible (or at least, not without major surgery)
David Lang
On Tue, Aug 03, 2010 at 03:23:00PM -0700, Arve Hj?nnev?g wrote:
> 2010/8/3 Paul E. McKenney <[email protected]>:
> > On Mon, Aug 02, 2010 at 09:18:27PM -0700, Arve Hj?nnev?g wrote:
> >> On Sat, Jul 31, 2010 at 10:58 AM, Paul E. McKenney
> >> <[email protected]> wrote:
> ...
> >> > o ? ? ? Statistics of the power-control actions taken by power-aware
> >> > ? ? ? ?applications must be provided, and must be keyed off of program
> >> > ? ? ? ?name.
> >>
> >> We don't key the stats off the program name, but having useful
> >> statistics is critical too us. The current code in linux-next does not
> >> appear to allow this (I'm referring to pm_stay_awake here, etc not
> >> pm-qos.)
> >
> > OK, maybe I was confused earlier. ?So you do not track statistics via
> > the device being open throughout the application's lifetime?
>
> The suspend blocker patchset does track statistics while the device is
> open, but it it not keyed of the program name. The name is passed from
> user-space and a single process can have the device open several
> times. The wakelock interface that we currently use just creates a new
> object every time it sees a new name and never frees it.
Ah, good to know!
Thanx, Paul
> ...
> >> > 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.)
> >>
> >> I would say it should suspend even if power aware applications are
> >> runnable. Most applications do not exclusively perform critical work.
> >
> > The point being that a power-aware application does not block suspend
> > -unless- it holds a suspend blocker, correct?
>
> Yes.
>
> >
> > Or am I missing some other subtlety?
>
> No.
>
> ...
> >> > 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.)
> >>
> >> Unconditional initialization makes it easier to add suspend blockers
> >> to existing kernel code since you don't have to add new failure exit
> >> paths. It is not a strong requirement.
> >
> > Ah, that makes more sense! ?I moved this to a new "NICE-TO-HAVES"
> > section. ?I also changed the last parenthesized sentence to read
> > "Such unconditional initialization reduces the intrusiveness of the
> > the Android patchset." ?Does that work?
> >
>
> Sure.
>
>
>
> --
> Arve Hj?nnev?g
On Mon, 2 Aug 2010 21:56:10 -0700
Arve Hjønnevåg <[email protected]> wrote:
> > non-obvious dependencies.
> >
>
> The dependencies is what made this solution uninteresting to us. For
> instance, we currently use cgroup scheduling to reduce the impact of
> some background tasks, but we occasionally saw a watchdog restart of
> the system process were critical services were waiting on a kernel
> mutex owned by a background task for more than 20 seconds. If we froze
> a cgroup instead, we would not hit this particular problem since tasks
> cannot be frozen while executing kernel code the same way they can be
> preempted, but nothing prevents a task from being frozen while holding
> a user-space resource.
>
one of the solutions we're looking at to solve this is to unfreeze the
cgroup on a regular basis (say, every 15 to 30 seconds) briefly to avoid
this kind of deadlock...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>
>> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
>>>
>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>
>>>> 2010/8/2 ?<[email protected]>:
>>>>>
>>>>> so what is the fundamental difference between deciding to go into
>>>>> low-power
>>>>> idle modes to wake up back up on a given point in the future and
>>>>> deciding
>>>>> that you are going to be idle for so long that you may as well suspend
>>>>> until
>>>>> there is user input?
>>>>>
>>>>
>>>> Low power idle modes are supposed to be transparent. Suspend stops the
>>>> monotonic clock, ignores ready threads and switches over to a separate
>>>> set of wakeup events/interrupts. We don't suspend until there is user
>>>> input, we suspend until there is a wakeup event (user-input, incoming
>>>> network data/phone-calls, alarms etc..).
>>>
>>> s/user input/wakeup event/ and my question still stands.
>>>
>>> low power modes are not transparent to the user in all cases (if the
>>> screen backlight dimms/shuts off a user reading something will
>>> notice, if the system switches to a lower clock speed it can impact
>>> user response time, etc) The system is making it's best guess as to
>>> how to best srve the user by sacraficing some capibilities to save
>>> power now so that the power can be available later.
>>>
>>> as I see it, suspending until a wakeup event (button press, incoming
>>> call, alarm, etc) is just another datapoint along the same path.
>>>
>>> If the system could not wake itself up to respond to user input,
>>> phone call, alarm, etc and needed the power button pressed to wake
>>> up (or shut down to the point where the battery could be removed and
>>> reinstalled a long time later), I would see things moving into a
>>> different category, but as long as the system has the ability to
>>> wake itself up later (and is still consuming power) I see the
>>> suspend as being in the same category as the other low-power modes
>>> (it's just more expensive to go in and out of)
>>>
>>>
>>> why should the suspend be put into a different category from the
>>> other low-power states?
>>
>> OK, I'll bite...
>
> thanks, this is not intended to be a trap.
>
>> From an Android perspective, the differences are as follows:
>>
>> 1. ? ? ?Deep idle states are entered only if there are no runnable tasks.
>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>> ? ? ? ?are tasks that are ready, willing, and able to run.
>
> Ok, this is a complication to what I'm proposing (and seems a little odd,
> but I can see how it can work), but not neccessarily a major problem. it
> depends on exactly how the decision is made to go into low power states
> and/or suspend. If this is done by an application that is able to look at
> either all activity or ignore one cgroup of processes at different times in
> it's calculations than this would work.
>
>> 2. ? ? ?There can be a set of input events that do not bring the system
>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>> ? ? ? ?of the Android-based smartphones ignores touchscreen input while
>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>
> I see this as simply being a matter of what devices are still enabled at the
> different power savings levels. At one level the touchscreen is still
> powered, while at another level it isn't, and at yet another level you have
> to hit the power soft-button. This isn't fundamentally different from
> powering off a USB peripheral that the system decides is idle (and then not
> seeing input from it until something else wakes the system)
The touchscreen on android devices is powered down long before we
suspend, so that is not a good example. There is still a significant
difference between suspend and idle though. In idle all interrupts
work, in suspend only interrupts that the driver has called
enable_irq_wake on will work (on platforms that support it).
>
>> 3. ? ? ?The system comes out of a deep idle state when a timer
>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>> ? ? ? ?case for timers is the same as that for deep idle states,
>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>> ? ? ? ?resulting discussions have produced much heat, but little
>> ? ? ? ?light. ?Such is life.)
>
> if you have the ability to wake for an alarm, you have the ability to wake
> for a timer (if from no other method than to set the alarm to when the timer
> tick would go off)
>
If you just program the alarm you will wake up see that the monotonic
clock has not advanced and set the alarm another n seconds into the
future. Or are proposing that suspend should be changed to keep the
monotonic clock running? If you are, why? We can enter the same
hardware states from idle, and modifying suspend to wake up more often
would increase the average power consumption in suspend, not improve
it for idle. In other words, if suspend wakes up as often as idle, why
use suspend?
>> There may well be others.
>>
>> Whether these distinctions are a good thing or a bad thing is one of
>> the topics of this discussion. ?But the distinctions themselves are
>> certainly very real, from what I can see.
>>
>> Or am I missing your point?
>
> these big distinction that I see as significant seem to be in the decision
> of when to go into the different states, and the difference between the
> states ?themselves seem to be less significant (and either very close to, or
> within the variation that already exists for power saving modes)
>
> If I'm right bout this, then it would seem to simplify the concept and
> change it from some really foreign android-only thing into a special case
> variation of existing core concepts.
Suspend is not an android only concept. The android extensions just
allow us to aggressively use suspend without loosing (or delaying)
wakeup events. On the hardware that we shipped we can enter the same
power mode from idle as we do in suspend, but we still use suspend
primarily because it stops the monotonic clock and all the timers that
use it. Changing suspend to behave more like an idle mode, which seems
to be what you are suggesting, would not buy us anything.
>
> you have many different power saving modes, the daemon (or kernel code) that
> is determining which mode to go into would need different logic (including,
> but not limited to the ability to be able to ignore one or more cgroups of
> processes). different power saving modes have different trade-offs, and some
> of them power down different peripherals (which is always a platform
> specific, if not system specific set of trade-offs)
>
The hardware specific idle hook can (and does) decide to go into any
power state from idle that does not disrupt any active devices.
> This all depends on the ability for the code that decides to switch power
> modes (including to trigger suspend) to be able to see things in sufficient
> detail to be able to do different things depending on the class of programs.
> I don't know enough about this code to know if this is the case or not, I
> really wish that someone familiar with the power saving code could either
> confirm that this is possible, or state that it's not possible (or at least,
> not without major surgery)
>
--
Arve Hj?nnev?g
On Tue, 3 Aug 2010 17:10:15 -0700
"Paul E. McKenney" <[email protected]> wrote:
>
> OK, I'll bite...
>
> >From an Android perspective, the differences are as follows:
>
> 1. Deep idle states are entered only if there are no runnable
> tasks. In contrast, opportunistic suspend can happen even when there
> are tasks that are ready, willing, and able to run.
for "system suspend", this is an absolutely valid statement.
for "use suspend as idle state", it's not so clearly valid.
(but this is sort of a separate problem, basically the "when do we
freeze the tasks that we don't like for power reasons" problem,
which in first order is independent on what kind of idle power state
you pick, and discussed extensively elsewhere in this thread)
>
> 2. There can be a set of input events that do not bring the
> system out of suspend, but which would bring the system out of a deep
> idle state. For example, I believe that it was stated that
> one of the Android-based smartphones ignores touchscreen input while
> suspended, but pays attention to it while in deep idle states.
I would argue that this is both a hardware specific issue, but also a
policy issue. From the user point of view, screen off with idle and
screen off with suspend aren't all that different (if my phone would
decide to idle rather than suspend because some app blocks suspend... I
wouldn't expect a difference in behavior when I touch the screen).
"Screen off -> don't honor touch after a bit" is almost an independent,
but very real, policy problem (and a forced one in suspend, I'll grant
you that). I could even argue that the policy decision "we don't care
about the touch screen input" is a pre-condition for entering suspend
(or in android speak, caring for touch screen input/having the touch
screen path active would be a suspend blocker)
>
> 3. The system comes out of a deep idle state when a timer
> expires. In contrast, timers cannot expire while the
> system is suspended. (This one is debatable: some people
> argue that timers are subject to jitter, and the suspend
> case for timers is the same as that for deep idle states,
> but with unbounded timer jitter. Others disagree. The
> resulting discussions have produced much heat, but little
> light. Such is life.)
I'll debate it even harder in that it's platform specific whether
timers can get the system out of suspend or not. Clearly on the Android
platform in question that's not the case, but for some of the Intel
phone silicon for example, timers CAN be wake sources to get you out of
suspend just fine. It just depend on which exact hw you talk about.
Generally, even if the fast timers aren't wake up sources, there'll be
some sort of alarm thing that you can pre-wake.. but yes you are right
in saying that's rather lame.
Either way, it's not a general property of suspend, but a property of
suspend on the specific platform in question.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Tue, 2010-08-03 at 15:08 -0700, Arve Hjønnevåg wrote:
> 2010/8/3 James Bottomley <[email protected]>:
> > On Mon, 2010-08-02 at 21:18 -0700, Arve Hjønnevåg wrote:
> >> > 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.
> >> >
> >>
> >> The problem with using open and close to prevent an allow suspend is
> >> not that it is too slow but that it interferes with collecting stats.
> >
> > Please elaborate on this. I expect the pm-qos stats interface will
> > collect stats across user open/close because that's how it currently
> > works. What's the problem?
> >
>
> The pm-qos interface creates the request object in open and destroys
> it in release just like the suspend blocker interface. We need stats
> for each client which is lost if you free the object every time you
> unblock suspend.
? right at the moment it doesn't do stats. I don't see why adding a per
pid or per name stat count on the long lived object won't work here.
> Or are you talking about user space opening and closing the stats
> interface (which does not cause any problems)?
There is no stat interface yet; it's for us to define.
> >> The wakelock code has a sysfs interface that allow you to use a
> >> open/write/close sequence to block or unblock suspend. There is no
> >> limit to the amount of kernel memory that a process can consume with
> >> this interface, so the suspend blocker patchset uses a /dev interface
> >> with ioctls to block or unblock suspend and it destroys the kernel
> >> object when the file descriptor is closed.
> >
> > This is an implementation detail only.
>
> There is no way fix it without changing the user space visible
> behavior of the API. The kernel does not know when it is safe to free
> the objects.
They're freed on destruction of the long lived kernel object or on user
space clear request. Surely that's definitive enough?
> > The pm-qos objects are long
> > lived, so their stats would be too. I would guess that explicit stat
> > clearing might be a useful option.
> >
>
> Which pm-qos objects are you referring to? The struct pm_qos_object
> that backs each pm-qos class is long lived (I don't know why this is
> named pm_qos_object), but we need stats in struct pm_qos_request_list.
Actually, why not two separate lists? one for the request and one for
the stats?
OK, so I'm tired and I've had a long flight to get to where I am, so I
may be a bit jaded, but this isn't fucking rocket science the question
is how do we implement what you want on what we have ... there looks to
be multiple useful solutions ... we just have to pick one and agree on
it (that's standard open source).
James
On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
>> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
>>>>
>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>> 2010/8/2 ?<[email protected]>:
>>>>>>
>>>>>> so what is the fundamental difference between deciding to go into
>>>>>> low-power
>>>>>> idle modes to wake up back up on a given point in the future and
>>>>>> deciding
>>>>>> that you are going to be idle for so long that you may as well suspend
>>>>>> until
>>>>>> there is user input?
>>>>>>
>>>>>
>>>>> Low power idle modes are supposed to be transparent. Suspend stops the
>>>>> monotonic clock, ignores ready threads and switches over to a separate
>>>>> set of wakeup events/interrupts. We don't suspend until there is user
>>>>> input, we suspend until there is a wakeup event (user-input, incoming
>>>>> network data/phone-calls, alarms etc..).
>>>>
>>>> s/user input/wakeup event/ and my question still stands.
>>>>
>>>> low power modes are not transparent to the user in all cases (if the
>>>> screen backlight dimms/shuts off a user reading something will
>>>> notice, if the system switches to a lower clock speed it can impact
>>>> user response time, etc) The system is making it's best guess as to
>>>> how to best srve the user by sacraficing some capibilities to save
>>>> power now so that the power can be available later.
>>>>
>>>> as I see it, suspending until a wakeup event (button press, incoming
>>>> call, alarm, etc) is just another datapoint along the same path.
>>>>
>>>> If the system could not wake itself up to respond to user input,
>>>> phone call, alarm, etc and needed the power button pressed to wake
>>>> up (or shut down to the point where the battery could be removed and
>>>> reinstalled a long time later), I would see things moving into a
>>>> different category, but as long as the system has the ability to
>>>> wake itself up later (and is still consuming power) I see the
>>>> suspend as being in the same category as the other low-power modes
>>>> (it's just more expensive to go in and out of)
>>>>
>>>>
>>>> why should the suspend be put into a different category from the
>>>> other low-power states?
>>>
>>> OK, I'll bite...
>>
>> thanks, this is not intended to be a trap.
>>
>>> From an Android perspective, the differences are as follows:
>>>
>>> 1. ? ? ?Deep idle states are entered only if there are no runnable tasks.
>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>>> ? ? ? ?are tasks that are ready, willing, and able to run.
>>
>> Ok, this is a complication to what I'm proposing (and seems a little odd,
>> but I can see how it can work), but not neccessarily a major problem. it
>> depends on exactly how the decision is made to go into low power states
>> and/or suspend. If this is done by an application that is able to look at
>> either all activity or ignore one cgroup of processes at different times in
>> it's calculations than this would work.
>>
>>> 2. ? ? ?There can be a set of input events that do not bring the system
>>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input while
>>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>>
>> I see this as simply being a matter of what devices are still enabled at the
>> different power savings levels. At one level the touchscreen is still
>> powered, while at another level it isn't, and at yet another level you have
>> to hit the power soft-button. This isn't fundamentally different from
>> powering off a USB peripheral that the system decides is idle (and then not
>> seeing input from it until something else wakes the system)
>
> The touchscreen on android devices is powered down long before we
> suspend, so that is not a good example. There is still a significant
> difference between suspend and idle though. In idle all interrupts
> work, in suspend only interrupts that the driver has called
> enable_irq_wake on will work (on platforms that support it).
are you talking about Android here or are you talking genricly across all
platforms?
>>
>>> 3. ? ? ?The system comes out of a deep idle state when a timer
>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>>> ? ? ? ?case for timers is the same as that for deep idle states,
>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>>> ? ? ? ?resulting discussions have produced much heat, but little
>>> ? ? ? ?light. ?Such is life.)
>>
>> if you have the ability to wake for an alarm, you have the ability to wake
>> for a timer (if from no other method than to set the alarm to when the timer
>> tick would go off)
>>
>
> If you just program the alarm you will wake up see that the monotonic
> clock has not advanced and set the alarm another n seconds into the
> future. Or are proposing that suspend should be changed to keep the
> monotonic clock running? If you are, why? We can enter the same
> hardware states from idle, and modifying suspend to wake up more often
> would increase the average power consumption in suspend, not improve
> it for idle. In other words, if suspend wakes up as often as idle, why
> use suspend?
no, I was thinking that you set the alarm to go off, and when it goes off
and wakes you up, you correct other local clocks before doing anything
else.
even if they wake up at the same time, you would use suspend instead of
idle if it saved more power (allowing for the power to get in and out of
suspend vs the power to get in and out of idle)
in this case, another reason you would consider using suspend over idle is
that you can suspend until the next timer that your privilaged
applications have set, and skip timers set by the non-privilaged
applications, resulting in more time asleep.
>>> There may well be others.
>>>
>>> Whether these distinctions are a good thing or a bad thing is one of
>>> the topics of this discussion. ?But the distinctions themselves are
>>> certainly very real, from what I can see.
>>>
>>> Or am I missing your point?
>>
>> these big distinction that I see as significant seem to be in the decision
>> of when to go into the different states, and the difference between the
>> states ?themselves seem to be less significant (and either very close to, or
>> within the variation that already exists for power saving modes)
>>
>> If I'm right bout this, then it would seem to simplify the concept and
>> change it from some really foreign android-only thing into a special case
>> variation of existing core concepts.
>
> Suspend is not an android only concept. The android extensions just
> allow us to aggressively use suspend without loosing (or delaying)
> wakeup events. On the hardware that we shipped we can enter the same
> power mode from idle as we do in suspend, but we still use suspend
> primarily because it stops the monotonic clock and all the timers that
> use it. Changing suspend to behave more like an idle mode, which seems
> to be what you are suggesting, would not buy us anything.
Ok, If I am understanding you correctly I think this is an important
point.
What Android calls suspend is not what other linux distros call suspend,
it's just a low-power mode with different wakeup rules.
Is this correct?
If this is the case it seems even more so that the android suspend should
be addressed by tieing into the power management/idle stuff rather than
the suspend/hibernate side of things
is the reason you want to stop the onotonic clock and the timers because
the applications need to be fooled into thinking no time has passed?
or is it to prevent extranious wakeups?
or is it to save additional power?
>> you have many different power saving modes, the daemon (or kernel code) that
>> is determining which mode to go into would need different logic (including,
>> but not limited to the ability to be able to ignore one or more cgroups of
>> processes). different power saving modes have different trade-offs, and some
>> of them power down different peripherals (which is always a platform
>> specific, if not system specific set of trade-offs)
>>
>
> The hardware specific idle hook can (and does) decide to go into any
> power state from idle that does not disrupt any active devices.
This I know is an Andoid specific thing. On other platforms power states
very definantly can make user visible changes.
>> This all depends on the ability for the code that decides to switch power
>> modes (including to trigger suspend) to be able to see things in sufficient
>> detail to be able to do different things depending on the class of programs.
>> I don't know enough about this code to know if this is the case or not, I
>> really wish that someone familiar with the power saving code could either
>> confirm that this is possible, or state that it's not possible (or at least,
>> not without major surgery)
On Tue, 3 Aug 2010, Arjan van de Ven wrote:
> On Tue, 3 Aug 2010 17:10:15 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>>
>> OK, I'll bite...
>>
>>> From an Android perspective, the differences are as follows:
>>
>> 1. Deep idle states are entered only if there are no runnable
>> tasks. In contrast, opportunistic suspend can happen even when there
>> are tasks that are ready, willing, and able to run.
>
> for "system suspend", this is an absolutely valid statement.
> for "use suspend as idle state", it's not so clearly valid.
> (but this is sort of a separate problem, basically the "when do we
> freeze the tasks that we don't like for power reasons" problem,
> which in first order is independent on what kind of idle power state
> you pick, and discussed extensively elsewhere in this thread)
note that what I'm speculating about would never freeze some of the tasks,
it would run everything if anything is run, but it would not consider the
actions of some of the programs when deciding if it can shutdown.
so if you have all your privilaged applications in long sleeps, but still
have your bouncing cows running, peggng the CPU, making noise, and
updating the screen, the system would decide the system is 'idle' and go
into the 'suspend' low power state until there is a wake activity.
but if you have a privilaged application doing other stuff (say you are
talking on the phone, have a GPS mapping program running and giving you
directions, etc), the bouncing cows would continue to run and there would
never be an attempt to freeze them while leaving the other stuff active.
David Lang
On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
> If you just program the alarm you will wake up see that the monotonic
> clock has not advanced and set the alarm another n seconds into the
> future. Or are proposing that suspend should be changed to keep the
> monotonic clock running?
You're supposed to fix the clock after you wake up. That's part of
the cost of going suspend.
OG.
On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <[email protected]> wrote:
> On Tue, 3 Aug 2010 17:10:15 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>>
>> OK, I'll bite...
>>
>> >From an Android perspective, the differences are as follows:
>>
>> 1. ? ?Deep idle states are entered only if there are no runnable
>> tasks. In contrast, opportunistic suspend can happen even when there
>> ? ? ? are tasks that are ready, willing, and able to run.
>
> for "system suspend", this is an absolutely valid statement.
> for "use suspend as idle state", it's not so clearly valid.
> (but this is sort of a separate problem, basically the "when do we
> freeze the tasks that we don't like for power reasons" problem,
> which in first order is independent on what kind of idle power state
> you pick, and discussed extensively elsewhere in this thread)
>
>>
>> 2. ? ?There can be a set of input events that do not bring the
>> system out of suspend, but which would bring the system out of a deep
>> ? ? ? idle state. ?For example, I believe that it was stated that
>> one of the Android-based smartphones ignores touchscreen input while
>> ? ? ? suspended, but pays attention to it while in deep idle states.
>
> I would argue that this is both a hardware specific issue, but also a
> policy issue. From the user point of view, screen off with idle and
> screen off with suspend aren't all that different (if my phone would
> decide to idle rather than suspend because some app blocks suspend... I
> wouldn't expect a difference in behavior when I touch the screen).
> "Screen off -> don't honor touch after a bit" is almost an independent,
> but very real, policy problem (and a forced one in suspend, I'll grant
> you that). I could even argue that the policy decision "we don't care
> about the touch screen input" is a pre-condition for entering suspend
> (or in android speak, caring for touch screen input/having the touch
> screen path active would be a suspend blocker)
>
>>
>> 3. ? ?The system comes out of a deep idle state when a timer
>> ? ? ? expires. ?In contrast, timers cannot expire while the
>> ? ? ? system is suspended. ?(This one is debatable: some people
>> ? ? ? argue that timers are subject to jitter, and the suspend
>> ? ? ? case for timers is the same as that for deep idle states,
>> ? ? ? but with unbounded timer jitter. ?Others disagree. ?The
>> ? ? ? resulting discussions have produced much heat, but little
>> ? ? ? light. ?Such is life.)
>
> I'll debate it even harder in that it's platform specific whether
> timers can get the system out of suspend or not. Clearly on the Android
> platform in question that's not the case, but for some of the Intel
> phone silicon for example, timers CAN be wake sources to get you out of
> suspend just fine. It just depend on which exact hw you talk about.
> Generally, even if the fast timers aren't wake up sources, there'll be
> some sort of alarm thing that you can pre-wake.. but yes you are right
> in saying that's rather lame.
> Either way, it's not a general property of suspend, but a property of
> suspend on the specific platform in question.
>
I disagree. On the msm platform the low level timer that brings us out
of the low power state is the same for idle and suspend. The
difference is where which kernel api the request comes from. In idle,
the next event on the clockevents device is usually the first event.
In suspend the generic kernel timekeeping code cancels this event and
the rtc wakeup event remains.
--
Arve Hj?nnev?g
2010/8/3 James Bottomley <[email protected]>:
> On Tue, 2010-08-03 at 15:08 -0700, Arve Hj?nnev?g wrote:
>> 2010/8/3 James Bottomley <[email protected]>:
>> > On Mon, 2010-08-02 at 21:18 -0700, Arve Hj?nnev?g wrote:
>> >> > 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.
>> >> >
>> >>
>> >> The problem with using open and close to prevent an allow suspend is
>> >> not that it is too slow but that it interferes with collecting stats.
>> >
>> > Please elaborate on this. ?I expect the pm-qos stats interface will
>> > collect stats across user open/close because that's how it currently
>> > works. ?What's the problem?
>> >
>>
>> The pm-qos interface creates the request object in open and destroys
>> it in release just like the suspend blocker interface. We need stats
>> for each client which is lost if you free the object every time you
>> unblock suspend.
>
> ? right at the moment it doesn't do stats. ?I don't see why adding a per
> pid or per name stat count on the long lived object won't work here.
>
>> Or are you talking about user space opening and closing the stats
>> interface (which does not cause any problems)?
>
> There is no stat interface yet; it's for us to define.
>
Then I don't know what you are asking. This specific requirement was
about the userspace interface to block and unblock suspend. The
existing pm-qos interface to update pm-qos requests is similar to the
user space suspend blocker interface (it has the same object
lifetime).
>> >> The wakelock code has a sysfs interface that allow you to use a
>> >> open/write/close sequence to block or unblock suspend. There is no
>> >> limit to the amount of kernel memory that a process can consume with
>> >> this interface, so the suspend blocker patchset uses a /dev interface
>> >> with ioctls to block or unblock suspend and it destroys the kernel
>> >> object when the file descriptor is closed.
>> >
>> > This is an implementation detail only.
>>
>> There is no way fix it without changing the user space visible
>> behavior of the API. The kernel does not know when it is safe to free
>> the objects.
>
> They're freed on destruction of the long lived kernel object or on user
> space clear request. ?Surely that's definitive enough?
>
What is a user-space clear request? Clearing all stats. Deleting a
suspend blocker? Unblocking suspend?
The android wakelock interface to userspace creates new wakelocks
every time it sees a new name. This was rejected on this list because
it does not put any limit on the amount of kernel memory used as a
result of calls from user space.
>> > The pm-qos objects are long
>> > lived, so their stats would be too. ?I would guess that explicit stat
>> > clearing might be a useful option.
>> >
>>
>> Which pm-qos objects are you referring to? The struct pm_qos_object
>> that backs each pm-qos class is long lived (I don't know why this is
>> named pm_qos_object), but we need stats in struct pm_qos_request_list.
>
> Actually, why not two separate lists? ?one for the request and one for
> the stats?
>
Why do you want to do another lookup? Is there a reason you don't want
stats in pm_qos_request_list?
> OK, so I'm tired and I've had a long flight to get to where I am, so I
> may be a bit jaded, but this isn't fucking rocket science the question
> is how do we implement what you want on what we have ... there looks to
> be multiple useful solutions ... we just have to pick one and agree on
> it (that's standard open source).
>
I don't think adding stats to pm-qos is hard. It is not as easy as the
wakelock/suspend blocker interface since the number of possible
request values is unknown, but we could for instance have stats on
default vs non-default request values. However, it is not at all clear
that switching our code to the pm-qos interface would make it
acceptable for mainline inclusion. The main objections to the last
suspend blocker patchset seemed to be that we should not use suspend
at all. There are also some new api in linux-next that try to solve
the same problem in an non android compatible way. Are drivers
supposed to use both this interface and pm-qos to prevent suspend?
--
Arve Hj?nnev?g
Hi,
On Tue, 3 Aug 2010 21:47:49 -0700 (PDT)
[email protected] wrote:
> > Suspend is not an android only concept. The android extensions just
> > allow us to aggressively use suspend without loosing (or delaying)
> > wakeup events. On the hardware that we shipped we can enter the same
> > power mode from idle as we do in suspend, but we still use suspend
> > primarily because it stops the monotonic clock and all the timers that
> > use it. Changing suspend to behave more like an idle mode, which seems
> > to be what you are suggesting, would not buy us anything.
>
> Ok, If I am understanding you correctly I think this is an important
> point.
>
> What Android calls suspend is not what other linux distros call suspend,
> it's just a low-power mode with different wakeup rules.
>
> Is this correct?
I think my laptop (x86-64) uses the same notion of suspend as Android.
I am confused now. Android 'suspend' is equivalent to
'echo "mem" > /sys/power/state'
Which distros call it "low-power mode with different wakeup rules"?
Gentoo doesnt. In KDE/Gnome it's also called suspend or suspend-to-ram
iirc.
Cheers,
Flo
2010/8/3 <[email protected]>:
> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>
>> On Tue, Aug 3, 2010 at 5:51 PM, ?<[email protected]> wrote:
>>>
>>> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>>>
>>>> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
>>>>>
>>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>>>
>>>>>> 2010/8/2 ?<[email protected]>:
>>>>>>>
>>>>>>> so what is the fundamental difference between deciding to go into
>>>>>>> low-power
>>>>>>> idle modes to wake up back up on a given point in the future and
>>>>>>> deciding
>>>>>>> that you are going to be idle for so long that you may as well
>>>>>>> suspend
>>>>>>> until
>>>>>>> there is user input?
>>>>>>>
>>>>>>
>>>>>> Low power idle modes are supposed to be transparent. Suspend stops the
>>>>>> monotonic clock, ignores ready threads and switches over to a separate
>>>>>> set of wakeup events/interrupts. We don't suspend until there is user
>>>>>> input, we suspend until there is a wakeup event (user-input, incoming
>>>>>> network data/phone-calls, alarms etc..).
>>>>>
>>>>> s/user input/wakeup event/ and my question still stands.
>>>>>
>>>>> low power modes are not transparent to the user in all cases (if the
>>>>> screen backlight dimms/shuts off a user reading something will
>>>>> notice, if the system switches to a lower clock speed it can impact
>>>>> user response time, etc) The system is making it's best guess as to
>>>>> how to best srve the user by sacraficing some capibilities to save
>>>>> power now so that the power can be available later.
>>>>>
>>>>> as I see it, suspending until a wakeup event (button press, incoming
>>>>> call, alarm, etc) is just another datapoint along the same path.
>>>>>
>>>>> If the system could not wake itself up to respond to user input,
>>>>> phone call, alarm, etc and needed the power button pressed to wake
>>>>> up (or shut down to the point where the battery could be removed and
>>>>> reinstalled a long time later), I would see things moving into a
>>>>> different category, but as long as the system has the ability to
>>>>> wake itself up later (and is still consuming power) I see the
>>>>> suspend as being in the same category as the other low-power modes
>>>>> (it's just more expensive to go in and out of)
>>>>>
>>>>>
>>>>> why should the suspend be put into a different category from the
>>>>> other low-power states?
>>>>
>>>> OK, I'll bite...
>>>
>>> thanks, this is not intended to be a trap.
>>>
>>>> From an Android perspective, the differences are as follows:
>>>>
>>>> 1. ? ? ?Deep idle states are entered only if there are no runnable
>>>> tasks.
>>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>>>> ? ? ? ?are tasks that are ready, willing, and able to run.
>>>
>>> Ok, this is a complication to what I'm proposing (and seems a little odd,
>>> but I can see how it can work), but not neccessarily a major problem. it
>>> depends on exactly how the decision is made to go into low power states
>>> and/or suspend. If this is done by an application that is able to look at
>>> either all activity or ignore one cgroup of processes at different times
>>> in
>>> it's calculations than this would work.
>>>
>>>> 2. ? ? ?There can be a set of input events that do not bring the system
>>>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input while
>>>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>>>
>>> I see this as simply being a matter of what devices are still enabled at
>>> the
>>> different power savings levels. At one level the touchscreen is still
>>> powered, while at another level it isn't, and at yet another level you
>>> have
>>> to hit the power soft-button. This isn't fundamentally different from
>>> powering off a USB peripheral that the system decides is idle (and then
>>> not
>>> seeing input from it until something else wakes the system)
>>
>> The touchscreen on android devices is powered down long before we
>> suspend, so that is not a good example. There is still a significant
>> difference between suspend and idle though. In idle all interrupts
>> work, in suspend only interrupts that the driver has called
>> enable_irq_wake on will work (on platforms that support it).
>
> are you talking about Android here or are you talking genricly across all
> platforms?
>
This appears to be the current Linux driver model. Old platform code
hardcoded the wakeup interrupts.
>>>
>>>> 3. ? ? ?The system comes out of a deep idle state when a timer
>>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>>>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>>>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>>>> ? ? ? ?case for timers is the same as that for deep idle states,
>>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>>>> ? ? ? ?resulting discussions have produced much heat, but little
>>>> ? ? ? ?light. ?Such is life.)
>>>
>>> if you have the ability to wake for an alarm, you have the ability to
>>> wake
>>> for a timer (if from no other method than to set the alarm to when the
>>> timer
>>> tick would go off)
>>>
>>
>> If you just program the alarm you will wake up see that the monotonic
>> clock has not advanced and set the alarm another n seconds into the
>> future. Or are proposing that suspend should be changed to keep the
>> monotonic clock running? If you are, why? We can enter the same
>> hardware states from idle, and modifying suspend to wake up more often
>> would increase the average power consumption in suspend, not improve
>> it for idle. In other words, if suspend wakes up as often as idle, why
>> use suspend?
>
> no, I was thinking that you set the alarm to go off, and when it goes off
> and wakes you up, you correct other local clocks before doing anything else.
>
> even if they wake up at the same time, you would use suspend instead of idle
> if it saved more power (allowing for the power to get in and out of suspend
> vs the power to get in and out of idle)
Suspend and idle use the same power state on the devices we shipped.
The power saving we get from suspend if from ignoring the timers.
>
> in this case, another reason you would consider using suspend over idle is
> that you can suspend until the next timer that your privilaged applications
> have set, and skip timers set by the non-privilaged applications, resulting
> in more time asleep.
Without wakelock or suspend blockers this can still break since a
privileged application may be waiting on a resource held by a
non-privileged application.
>
>>>> There may well be others.
>>>>
>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>> the topics of this discussion. ?But the distinctions themselves are
>>>> certainly very real, from what I can see.
>>>>
>>>> Or am I missing your point?
>>>
>>> these big distinction that I see as significant seem to be in the
>>> decision
>>> of when to go into the different states, and the difference between the
>>> states ?themselves seem to be less significant (and either very close to,
>>> or
>>> within the variation that already exists for power saving modes)
>>>
>>> If I'm right bout this, then it would seem to simplify the concept and
>>> change it from some really foreign android-only thing into a special case
>>> variation of existing core concepts.
>>
>> Suspend is not an android only concept. The android extensions just
>> allow us to aggressively use suspend without loosing (or delaying)
>> wakeup events. On the hardware that we shipped we can enter the same
>> power mode from idle as we do in suspend, but we still use suspend
>> primarily because it stops the monotonic clock and all the timers that
>> use it. Changing suspend to behave more like an idle mode, which seems
>> to be what you are suggesting, would not buy us anything.
>
> Ok, If I am understanding you correctly I think this is an important point.
>
> What Android calls suspend is not what other linux distros call suspend,
> it's just a low-power mode with different wakeup rules.
>
> Is this correct?
>
No. Android suspend is Linux suspend. We just enter it more frequently.
> If this is the case it seems even more so that the android suspend should be
> addressed by tieing into the power management/idle stuff rather than the
> suspend/hibernate side of things
>
> is the reason you want to stop the onotonic clock and the timers because the
> applications need to be fooled into thinking no time has passed?
>
Yes, but this is not an Android extension, it is part of the normal
Linux suspend sequence.
> or is it to prevent extranious wakeups?
>
That too.
> or is it to save additional power?
>
No (assuming you are asking about the clock), the actual hardware
clock (on msm) stops even in idle but it is resynchronized on wakeup
with a clock that never stops when used from idle.
>>> you have many different power saving modes, the daemon (or kernel code)
>>> that
>>> is determining which mode to go into would need different logic
>>> (including,
>>> but not limited to the ability to be able to ignore one or more cgroups
>>> of
>>> processes). different power saving modes have different trade-offs, and
>>> some
>>> of them power down different peripherals (which is always a platform
>>> specific, if not system specific set of trade-offs)
>>>
>>
>> The hardware specific idle hook can (and does) decide to go into any
>> power state from idle that does not disrupt any active devices.
>
> This I know is an Andoid specific thing. On other platforms power states
> very definantly can make user visible changes.
How is this Android specific?
>
>>> This all depends on the ability for the code that decides to switch power
>>> modes (including to trigger suspend) to be able to see things in
>>> sufficient
>>> detail to be able to do different things depending on the class of
>>> programs.
>>> I don't know enough about this code to know if this is the case or not, I
>>> really wish that someone familiar with the power saving code could either
>>> confirm that this is possible, or state that it's not possible (or at
>>> least,
>>> not without major surgery)
--
Arve Hj?nnev?g
2010/8/3 Olivier Galibert <[email protected]>:
> On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
>> If you just program the alarm you will wake up see that the monotonic
>> clock has not advanced and set the alarm another n seconds into the
>> future. Or are proposing that suspend should be changed to keep the
>> monotonic clock running?
>
> You're supposed to fix the clock after you wake up. ?That's part of
> the cost of going suspend.
I'm not sure what you are referring to. The generic Linux timekeeping
code makes sure the monotonic clock stops while the system is
suspended regardless of what values the (hardware specific)
clocksource returns.
--
Arve Hj?nnev?g
On Tue, 3 Aug 2010 21:55:07 -0700 (PDT)
[email protected] wrote:
> On Tue, 3 Aug 2010, Arjan van de Ven wrote:
>
> > On Tue, 3 Aug 2010 17:10:15 -0700
> > "Paul E. McKenney" <[email protected]> wrote:
> >>
> >> OK, I'll bite...
> >>
> >>> From an Android perspective, the differences are as follows:
> >>
> >> 1. Deep idle states are entered only if there are no runnable
> >> tasks. In contrast, opportunistic suspend can happen even when there
> >> are tasks that are ready, willing, and able to run.
> >
> > for "system suspend", this is an absolutely valid statement.
> > for "use suspend as idle state", it's not so clearly valid.
> > (but this is sort of a separate problem, basically the "when do we
> > freeze the tasks that we don't like for power reasons" problem,
> > which in first order is independent on what kind of idle power state
> > you pick, and discussed extensively elsewhere in this thread)
>
> note that what I'm speculating about would never freeze some of the tasks,
> it would run everything if anything is run, but it would not consider the
> actions of some of the programs when deciding if it can shutdown.
>
> so if you have all your privilaged applications in long sleeps, but still
> have your bouncing cows running, peggng the CPU, making noise, and
> updating the screen, the system would decide the system is 'idle' and go
> into the 'suspend' low power state until there is a wake activity.
>
> but if you have a privilaged application doing other stuff (say you are
> talking on the phone, have a GPS mapping program running and giving you
> directions, etc), the bouncing cows would continue to run and there would
> never be an attempt to freeze them while leaving the other stuff active.
>
> David Lang
I think the only difference between your proposition and the
current android practice is that in your scheme the partition is along
the process/task boundary (i.e. good apps vs bad apps) whereas the
android looks at actions or events or ... let's call it "stuff" and
blocks suspend whenever "stuff" needs to be done.
The main thing is that even an process that is allowed to block suspend
doesn't do so all the time. Only when it is critical that "stuff" get's
done right away.
One way to make an application work the same way with your scheme (as
I understand it) on android could be to split the
application into an "blocker" part, that is not part of the
"ignore-cgroup" (the "trusted" part) and another one that is in the
"ignore-cgroup" (the "untrusted" part). Whenever the untrusted part
needs to block suspend it notices the "trusted" part via ipc and the
trusted part goes into some sort of "activity loop". This looks kind of
stupid. But I bet it is what application developers are going to do if
there is no provision for a flexible runtime enable/disable "suspend
blocker".
hmmm...
Cheers,
Flo
On Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hj?nnev?g wrote:
> 2010/8/3 Olivier Galibert <[email protected]>:
> > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
> >> If you just program the alarm you will wake up see that the monotonic
> >> clock has not advanced and set the alarm another n seconds into the
> >> future. Or are proposing that suspend should be changed to keep the
> >> monotonic clock running?
> >
> > You're supposed to fix the clock after you wake up. ?That's part of
> > the cost of going suspend.
>
> I'm not sure what you are referring to. The generic Linux timekeeping
> code makes sure the monotonic clock stops while the system is
> suspended regardless of what values the (hardware specific)
> clocksource returns.
That just means the android-like suspend should not act in that
specific area the same as the generic suspend to ram. Which is not
entirely surprising. In any case, it's not "keep the monotonic clock
running", which would cost power. It's fix it up afterwards, using
the same means you already do but perhaps at a higher level currently.
People don't want to see the wrong time of the day just because the
phone went to suspend. Laptop STR is different in perception because
it shuts down things people don't want to see shutdown just by being
idle, namely wifi connectivity.
If your next polling timer is in half an hour and the screen/touchpad
are off, you want to go as low in power as possible until then, and
that's the deepest level of idle you can find that responds to alarms
which may happen to be called suspend. But from a user point of view,
it's just another idle level. And from a power management code/policy
decisions point of view, it should be the same.
OG.
On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/3 <[email protected]>:
>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> On Tue, Aug 3, 2010 at 5:51 PM, ?<[email protected]> wrote:
>>>>
>>>> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>> OK, I'll bite...
>>>>
>>>> thanks, this is not intended to be a trap.
>>>>
>>>>> From an Android perspective, the differences are as follows:
>>>>>
>>>>> 1. ? ? ?Deep idle states are entered only if there are no runnable
>>>>> tasks.
>>>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>>>>> ? ? ? ?are tasks that are ready, willing, and able to run.
>>>>
>>>> Ok, this is a complication to what I'm proposing (and seems a little odd,
>>>> but I can see how it can work), but not neccessarily a major problem. it
>>>> depends on exactly how the decision is made to go into low power states
>>>> and/or suspend. If this is done by an application that is able to look at
>>>> either all activity or ignore one cgroup of processes at different times
>>>> in
>>>> it's calculations than this would work.
>>>>
>>>>> 2. ? ? ?There can be a set of input events that do not bring the system
>>>>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>>>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>>>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input while
>>>>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>>>>
>>>> I see this as simply being a matter of what devices are still enabled at
>>>> the
>>>> different power savings levels. At one level the touchscreen is still
>>>> powered, while at another level it isn't, and at yet another level you
>>>> have
>>>> to hit the power soft-button. This isn't fundamentally different from
>>>> powering off a USB peripheral that the system decides is idle (and then
>>>> not
>>>> seeing input from it until something else wakes the system)
>>>
>>> The touchscreen on android devices is powered down long before we
>>> suspend, so that is not a good example. There is still a significant
>>> difference between suspend and idle though. In idle all interrupts
>>> work, in suspend only interrupts that the driver has called
>>> enable_irq_wake on will work (on platforms that support it).
>>
>> are you talking about Android here or are you talking genricly across all
>> platforms?
>>
>
> This appears to be the current Linux driver model. Old platform code
> hardcoded the wakeup interrupts.
not quite the question I was trying (and failing) to ask, but from the
answer it sounds like setting suspend to wake up on all interrupts is
the same as idle.
so here suspend is looking like just a variation of low-power idle
(different wakeup criteria)
>>>>> 3. ? ? ?The system comes out of a deep idle state when a timer
>>>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>>>>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>>>>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>>>>> ? ? ? ?case for timers is the same as that for deep idle states,
>>>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>>>>> ? ? ? ?resulting discussions have produced much heat, but little
>>>>> ? ? ? ?light. ?Such is life.)
>>>>
>>>> if you have the ability to wake for an alarm, you have the ability to
>>>> wake
>>>> for a timer (if from no other method than to set the alarm to when the
>>>> timer
>>>> tick would go off)
>>>>
>>>
>>> If you just program the alarm you will wake up see that the monotonic
>>> clock has not advanced and set the alarm another n seconds into the
>>> future. Or are proposing that suspend should be changed to keep the
>>> monotonic clock running? If you are, why? We can enter the same
>>> hardware states from idle, and modifying suspend to wake up more often
>>> would increase the average power consumption in suspend, not improve
>>> it for idle. In other words, if suspend wakes up as often as idle, why
>>> use suspend?
>>
>> no, I was thinking that you set the alarm to go off, and when it goes off
>> and wakes you up, you correct other local clocks before doing anything else.
>>
>> even if they wake up at the same time, you would use suspend instead of idle
>> if it saved more power (allowing for the power to get in and out of suspend
>> vs the power to get in and out of idle)
>
> Suspend and idle use the same power state on the devices we shipped.
> The power saving we get from suspend if from ignoring the timers.
Ok, so if you set the alarm to the next time the timer for a privilaged
task would run and wake up then to be completely transparent to the
privilaged task, or you could decide to disable the timers as well
again, this looks like suspend and idle are very closely related.
>> in this case, another reason you would consider using suspend over idle is
>> that you can suspend until the next timer that your privilaged applications
>> have set, and skip timers set by the non-privilaged applications, resulting
>> in more time asleep.
>
> Without wakelock or suspend blockers this can still break since a
> privileged application may be waiting on a resource held by a
> non-privileged application.
since the non-privilaged application is never frozen when a privilaged
application is running, I'm not sure how you would get this to happen that
wouldn't also be a problem with wakelocks.
if you want to have a privilaged application keep the system awake while
it waits for a non-privilaged application, all it would need to do is to
set a timer near enough in the future that it's considered 'awake' all the
time. this will cost a context switch every timeout period (for the
application to check that it's still waiting and set the next timer), but
that's pretty cheap.
one thing this would destroy is the stats currently built around the
wakelock, but since they would be replaced by stats of exactly the type of
thing that powertop was written to deal with, I don't see this as a
problem (powertop would just have to learn a mode where it ignores the
non-privilaged tasks).consolodating tools is a good thing.
>>>>> There may well be others.
>>>>>
>>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>>> the topics of this discussion. ?But the distinctions themselves are
>>>>> certainly very real, from what I can see.
>>>>>
>>>>> Or am I missing your point?
>>>>
>>>> these big distinction that I see as significant seem to be in the
>>>> decision
>>>> of when to go into the different states, and the difference between the
>>>> states ?themselves seem to be less significant (and either very close to,
>>>> or
>>>> within the variation that already exists for power saving modes)
>>>>
>>>> If I'm right bout this, then it would seem to simplify the concept and
>>>> change it from some really foreign android-only thing into a special case
>>>> variation of existing core concepts.
>>>
>>> Suspend is not an android only concept. The android extensions just
>>> allow us to aggressively use suspend without loosing (or delaying)
>>> wakeup events. On the hardware that we shipped we can enter the same
>>> power mode from idle as we do in suspend, but we still use suspend
>>> primarily because it stops the monotonic clock and all the timers that
>>> use it. Changing suspend to behave more like an idle mode, which seems
>>> to be what you are suggesting, would not buy us anything.
>>
>> Ok, If I am understanding you correctly I think this is an important point.
>>
>> What Android calls suspend is not what other linux distros call suspend,
>> it's just a low-power mode with different wakeup rules.
>>
>> Is this correct?
>>
>
> No. Android suspend is Linux suspend. We just enter it more frequently.
In Linux, a full suspend normally takes the system down to a mode that
can't be reached by the normal idle mechnism (including powering down
peripherals). It also takes significantly different actions to wake up.
What you are describing seems much milder than that.
>> If this is the case it seems even more so that the android suspend should be
>> addressed by tieing into the power management/idle stuff rather than the
>> suspend/hibernate side of things
>>
>> is the reason you want to stop the onotonic clock and the timers because the
>> applications need to be fooled into thinking no time has passed?
>>
>
> Yes, but this is not an Android extension, it is part of the normal
> Linux suspend sequence.
no, as noted by others in this thread, normal linux suspend/resume
modifies the clock to show that time has passed since the suspend
happened.
>> or is it to prevent extranious wakeups?
>>
> That too.
as noted above, this sounds like it's configurable.
>> or is it to save additional power?
>>
> No (assuming you are asking about the clock), the actual hardware
> clock (on msm) stops even in idle but it is resynchronized on wakeup
> with a clock that never stops when used from idle.
so I'm left not understanding the huge desire to stop the monotonic clock.
>>>> you have many different power saving modes, the daemon (or kernel code)
>>>> that
>>>> is determining which mode to go into would need different logic
>>>> (including,
>>>> but not limited to the ability to be able to ignore one or more cgroups
>>>> of
>>>> processes). different power saving modes have different trade-offs, and
>>>> some
>>>> of them power down different peripherals (which is always a platform
>>>> specific, if not system specific set of trade-offs)
>>>>
>>>
>>> The hardware specific idle hook can (and does) decide to go into any
>>> power state from idle that does not disrupt any active devices.
>>
>> This I know is an Andoid specific thing. On other platforms power states
>> very definantly can make user visible changes.
>
> How is this Android specific?
you are stating that this must be suspend because low-power idle must be
transparent to the user.
I am saying that on Linux, low-power idle commonly is not transparent to
the user, so the requirement for it to be transparent (therefor putting
the suspend into a different category) is an Android only requirement.
David Lang
On Wed, 4 Aug 2010, Florian Mickler wrote:
> Subject: Re: Attempted summary of suspend-blockers LKML thread
>
> On Tue, 3 Aug 2010 21:55:07 -0700 (PDT)
> [email protected] wrote:
>
>> On Tue, 3 Aug 2010, Arjan van de Ven wrote:
>>
>>> On Tue, 3 Aug 2010 17:10:15 -0700
>>> "Paul E. McKenney" <[email protected]> wrote:
>>>>
>>>> OK, I'll bite...
>>>>
>>>>> From an Android perspective, the differences are as follows:
>>>>
>>>> 1. Deep idle states are entered only if there are no runnable
>>>> tasks. In contrast, opportunistic suspend can happen even when there
>>>> are tasks that are ready, willing, and able to run.
>>>
>>> for "system suspend", this is an absolutely valid statement.
>>> for "use suspend as idle state", it's not so clearly valid.
>>> (but this is sort of a separate problem, basically the "when do we
>>> freeze the tasks that we don't like for power reasons" problem,
>>> which in first order is independent on what kind of idle power state
>>> you pick, and discussed extensively elsewhere in this thread)
>>
>> note that what I'm speculating about would never freeze some of the tasks,
>> it would run everything if anything is run, but it would not consider the
>> actions of some of the programs when deciding if it can shutdown.
>>
>> so if you have all your privilaged applications in long sleeps, but still
>> have your bouncing cows running, peggng the CPU, making noise, and
>> updating the screen, the system would decide the system is 'idle' and go
>> into the 'suspend' low power state until there is a wake activity.
>>
>> but if you have a privilaged application doing other stuff (say you are
>> talking on the phone, have a GPS mapping program running and giving you
>> directions, etc), the bouncing cows would continue to run and there would
>> never be an attempt to freeze them while leaving the other stuff active.
>>
>> David Lang
>
> I think the only difference between your proposition and the
> current android practice is that in your scheme the partition is along
> the process/task boundary (i.e. good apps vs bad apps) whereas the
> android looks at actions or events or ... let's call it "stuff" and
> blocks suspend whenever "stuff" needs to be done.
with the caviot that only privilaged applications are allowed to define
that "stuff" needs to be done
> The main thing is that even an process that is allowed to block suspend
> doesn't do so all the time. Only when it is critical that "stuff" get's
> done right away.
effectivly, only when it's important that "stuff" gets done at all. With
current smartphone battery capacities it's not uncommon that the phone
could be in suspend until the battery dies, since suspend is not zero
power.
> One way to make an application work the same way with your scheme (as
> I understand it) on android could be to split the
> application into an "blocker" part, that is not part of the
> "ignore-cgroup" (the "trusted" part) and another one that is in the
> "ignore-cgroup" (the "untrusted" part). Whenever the untrusted part
> needs to block suspend it notices the "trusted" part via ipc and the
> trusted part goes into some sort of "activity loop". This looks kind of
> stupid. But I bet it is what application developers are going to do if
> there is no provision for a flexible runtime enable/disable "suspend
> blocker".
remember that only "trusted" applications were allowed to set the
suspend-blocker/wakelock flag in the first place.
my thinking is that since "trusted" applications are assumed to be well
written (or they can just raise the suspend-blocker/wakelock and keep the
phone from ever sleeping) they should be able to be trusted to sleep
appropriately so that if they aren't actually doing anything important the
system can go ahead and go to sleep.
Since powertop was designed to find ill-bahaved applications, you would
still be able to point the finger at the offenders.
yes, you could trivially have a 'keep me awake' daemon that other apps can
talk to to request the system stay awake (the same way you could with a
suspend-blocker/wakelock). The "activity loop" for such a
daemon can be pretty trivial, set a timer just a little shorter than the
idle-go-to-suspend timeout, sleep that long and reset the timer.
I could be mistaken here, but my assumption is that since normal
applications running would never get trigger the wakelock except when
there is user input, the timeout here is on the order of 10s of seconds,
if not a few minutes. having a privilaged application wake up once every
several seconds is not going to be significant to anything other than
things looking for the system being idle for X amount of time..
Even if this is done, having a userspace 'wakelock' daemon that works this
way is significantly better in many people's eyes than having the kernel
implement this policy. It's much easier to put application/platform
specific logic in the userspace daemon than into the kernel (say, things
like 'any app can request a delay for up to X amount of time, but after
that they cannot request it again for Y amount of time, except ....)
David Lang
2010/8/3 Olivier Galibert <[email protected]>:
> On Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hj?nnev?g wrote:
>> 2010/8/3 Olivier Galibert <[email protected]>:
>> > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
>> >> If you just program the alarm you will wake up see that the monotonic
>> >> clock has not advanced and set the alarm another n seconds into the
>> >> future. Or are proposing that suspend should be changed to keep the
>> >> monotonic clock running?
>> >
>> > You're supposed to fix the clock after you wake up. ?That's part of
>> > the cost of going suspend.
>>
>> I'm not sure what you are referring to. The generic Linux timekeeping
>> code makes sure the monotonic clock stops while the system is
>> suspended regardless of what values the (hardware specific)
>> clocksource returns.
>
> That just means the android-like suspend should not act in that
> specific area the same as the generic suspend to ram. ?Which is not
Huh? Android uses the generic suspend code.
> entirely surprising. ?In any case, it's not "keep the monotonic clock
> running", which would cost power. ?It's fix it up afterwards, using
> the same means you already do but perhaps at a higher level currently.
> People don't want to see the wrong time of the day just because the
> phone went to suspend. ?Laptop STR is different in perception because
The monotonic clock is not the same as the realtime clock which is
used for time of day.
> it shuts down things people don't want to see shutdown just by being
> idle, namely wifi connectivity.
>
> If your next polling timer is in half an hour and the screen/touchpad
> are off, you want to go as low in power as possible until then, and
> that's the deepest level of idle you can find that responds to alarms
> which may happen to be called suspend. ?But from a user point of view,
Calling the deepest idle state suspend is just confusing. Linux
suspend has a different api than idle. In suspend every driver that
has a suspend hook is notified. Also, once cpu can be idle while
another cpu is running. Suspend is a system wide.
> it's just another idle level. ?And from a power management code/policy
> decisions point of view, it should be the same.
>
--
Arve Hj?nnev?g
2010/8/3 <[email protected]>:
> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/3 ?<[email protected]>:
>>>
>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>
>>>> On Tue, Aug 3, 2010 at 5:51 PM, ?<[email protected]> wrote:
>>>>>
>>>>> On Tue, 3 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>>> OK, I'll bite...
>>>>>
>>>>> thanks, this is not intended to be a trap.
>>>>>
>>>>>> From an Android perspective, the differences are as follows:
>>>>>>
>>>>>> 1. ? ? ?Deep idle states are entered only if there are no runnable
>>>>>> tasks.
>>>>>> ? ? ? ?In contrast, opportunistic suspend can happen even when there
>>>>>> ? ? ? ?are tasks that are ready, willing, and able to run.
>>>>>
>>>>> Ok, this is a complication to what I'm proposing (and seems a little
>>>>> odd,
>>>>> but I can see how it can work), but not neccessarily a major problem.
>>>>> it
>>>>> depends on exactly how the decision is made to go into low power states
>>>>> and/or suspend. If this is done by an application that is able to look
>>>>> at
>>>>> either all activity or ignore one cgroup of processes at different
>>>>> times
>>>>> in
>>>>> it's calculations than this would work.
>>>>>
>>>>>> 2. ? ? ?There can be a set of input events that do not bring the
>>>>>> system
>>>>>> ? ? ? ?out of suspend, but which would bring the system out of a deep
>>>>>> ? ? ? ?idle state. ?For example, I believe that it was stated that one
>>>>>> ? ? ? ?of the Android-based smartphones ignores touchscreen input
>>>>>> while
>>>>>> ? ? ? ?suspended, but pays attention to it while in deep idle states.
>>>>>
>>>>> I see this as simply being a matter of what devices are still enabled
>>>>> at
>>>>> the
>>>>> different power savings levels. At one level the touchscreen is still
>>>>> powered, while at another level it isn't, and at yet another level you
>>>>> have
>>>>> to hit the power soft-button. This isn't fundamentally different from
>>>>> powering off a USB peripheral that the system decides is idle (and then
>>>>> not
>>>>> seeing input from it until something else wakes the system)
>>>>
>>>> The touchscreen on android devices is powered down long before we
>>>> suspend, so that is not a good example. There is still a significant
>>>> difference between suspend and idle though. In idle all interrupts
>>>> work, in suspend only interrupts that the driver has called
>>>> enable_irq_wake on will work (on platforms that support it).
>>>
>>> are you talking about Android here or are you talking genricly across all
>>> platforms?
>>>
>>
>> This appears to be the current Linux driver model. Old platform code
>> hardcoded the wakeup interrupts.
>
> not quite the question I was trying (and failing) to ask, but from the
> answer it sounds like setting suspend to wake up on all interrupts is the
> same as idle.
>
No, suspend does a lot more than idle.
> so here suspend is looking like just a variation of low-power idle
> (different wakeup criteria)
>
>>>>>> 3. ? ? ?The system comes out of a deep idle state when a timer
>>>>>> ? ? ? ?expires. ?In contrast, timers cannot expire while the
>>>>>> ? ? ? ?system is suspended. ?(This one is debatable: some people
>>>>>> ? ? ? ?argue that timers are subject to jitter, and the suspend
>>>>>> ? ? ? ?case for timers is the same as that for deep idle states,
>>>>>> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
>>>>>> ? ? ? ?resulting discussions have produced much heat, but little
>>>>>> ? ? ? ?light. ?Such is life.)
>>>>>
>>>>> if you have the ability to wake for an alarm, you have the ability to
>>>>> wake
>>>>> for a timer (if from no other method than to set the alarm to when the
>>>>> timer
>>>>> tick would go off)
>>>>>
>>>>
>>>> If you just program the alarm you will wake up see that the monotonic
>>>> clock has not advanced and set the alarm another n seconds into the
>>>> future. Or are proposing that suspend should be changed to keep the
>>>> monotonic clock running? If you are, why? We can enter the same
>>>> hardware states from idle, and modifying suspend to wake up more often
>>>> would increase the average power consumption in suspend, not improve
>>>> it for idle. In other words, if suspend wakes up as often as idle, why
>>>> use suspend?
>>>
>>> no, I was thinking that you set the alarm to go off, and when it goes off
>>> and wakes you up, you correct other local clocks before doing anything
>>> else.
>>>
>>> even if they wake up at the same time, you would use suspend instead of
>>> idle
>>> if it saved more power (allowing for the power to get in and out of
>>> suspend
>>> vs the power to get in and out of idle)
>>
>> Suspend and idle use the same power state on the devices we shipped.
>> The power saving we get from suspend if from ignoring the timers.
>
> Ok, so if you set the alarm to the next time the timer for a privilaged task
> would run and wake up then to be completely transparent to the privilaged
> task, or you could decide to disable the timers as well
>
> again, this looks like suspend and idle are very closely related.
>
>>> in this case, another reason you would consider using suspend over idle
>>> is
>>> that you can suspend until the next timer that your privilaged
>>> applications
>>> have set, and skip timers set by the non-privilaged applications,
>>> resulting
>>> in more time asleep.
>>
>> Without wakelock or suspend blockers this can still break since a
>> privileged application may be waiting on a resource held by a
>> non-privileged application.
>
> since the non-privilaged application is never frozen when a privilaged
> application is running, I'm not sure how you would get this to happen that
> wouldn't also be a problem with wakelocks.
With wakelocks we annotate that we have important work to do, until
that work is accomplished we do not suspend. If you modify the idle
code ignore some processes' timers the system may get stuck in idle
while waiting for a non-privileged application to release a resource.
>
> if you want to have a privilaged application keep the system awake while it
> waits for a non-privilaged application, all it would need to do is to set a
> timer near enough in the future that it's considered 'awake' all the time.
> this will cost a context switch every timeout period (for the application to
> check that it's still waiting and set the next timer), but that's pretty
> cheap.
No, this will kill your idle power.
>
> one thing this would destroy is the stats currently built around the
> wakelock, but since they would be replaced by stats of exactly the type of
> thing that powertop was written to deal with, I don't see this as a problem
> (powertop would just have to learn a mode where it ignores the
> non-privilaged tasks).consolodating tools is a good thing.
>
>>>>>> There may well be others.
>>>>>>
>>>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>>>> the topics of this discussion. ?But the distinctions themselves are
>>>>>> certainly very real, from what I can see.
>>>>>>
>>>>>> Or am I missing your point?
>>>>>
>>>>> these big distinction that I see as significant seem to be in the
>>>>> decision
>>>>> of when to go into the different states, and the difference between the
>>>>> states ?themselves seem to be less significant (and either very close
>>>>> to,
>>>>> or
>>>>> within the variation that already exists for power saving modes)
>>>>>
>>>>> If I'm right bout this, then it would seem to simplify the concept and
>>>>> change it from some really foreign android-only thing into a special
>>>>> case
>>>>> variation of existing core concepts.
>>>>
>>>> Suspend is not an android only concept. The android extensions just
>>>> allow us to aggressively use suspend without loosing (or delaying)
>>>> wakeup events. On the hardware that we shipped we can enter the same
>>>> power mode from idle as we do in suspend, but we still use suspend
>>>> primarily because it stops the monotonic clock and all the timers that
>>>> use it. Changing suspend to behave more like an idle mode, which seems
>>>> to be what you are suggesting, would not buy us anything.
>>>
>>> Ok, If I am understanding you correctly I think this is an important
>>> point.
>>>
>>> What Android calls suspend is not what other linux distros call suspend,
>>> it's just a low-power mode with different wakeup rules.
>>>
>>> Is this correct?
>>>
>>
>> No. Android suspend is Linux suspend. We just enter it more frequently.
>
> In Linux, a full suspend normally takes the system down to a mode that can't
> be reached by the normal idle mechnism (including powering down
> peripherals). It also takes significantly different actions to wake up. What
> you are describing seems much milder than that.
We use the normal suspend sequence. The shipping hardware we have just
don't need to do lot
>
>>> If this is the case it seems even more so that the android suspend should
>>> be
>>> addressed by tieing into the power management/idle stuff rather than the
>>> suspend/hibernate side of things
>>>
>>> is the reason you want to stop the onotonic clock and the timers because
>>> the
>>> applications need to be fooled into thinking no time has passed?
>>>
>>
>> Yes, but this is not an Android extension, it is part of the normal
>> Linux suspend sequence.
>
> no, as noted by others in this thread, normal linux suspend/resume modifies
> the clock to show that time has passed since the suspend happened.
>
The monotonic clock always stops. There are a few different ways to
maintain the realtime clock and we use one of them.
>>> or is it to prevent extranious wakeups?
>>>
>> That too.
>
> as noted above, this sounds like it's configurable.
>
>>> or is it to save additional power?
>>>
>> No (assuming you are asking about the clock), the actual hardware
>> clock (on msm) stops even in idle but it is resynchronized on wakeup
>> with a clock that never stops when used from idle.
>
> so I'm left not understanding the huge desire to stop the monotonic clock.
>
If you ignore the timers and don't stop the clock they are based on,
you break a lot of apps when you resume (watchdogs and timeouts
trigger). If you don't ignore timers, you can't sleep very long with
existing software.
>>>>> you have many different power saving modes, the daemon (or kernel code)
>>>>> that
>>>>> is determining which mode to go into would need different logic
>>>>> (including,
>>>>> but not limited to the ability to be able to ignore one or more cgroups
>>>>> of
>>>>> processes). different power saving modes have different trade-offs, and
>>>>> some
>>>>> of them power down different peripherals (which is always a platform
>>>>> specific, if not system specific set of trade-offs)
>>>>>
>>>>
>>>> The hardware specific idle hook can (and does) decide to go into any
>>>> power state from idle that does not disrupt any active devices.
>>>
>>> This I know is an Andoid specific thing. On other platforms power states
>>> very definantly can make user visible changes.
>>
>> How is this Android specific?
>
> you are stating that this must be suspend because low-power idle must be
> transparent to the user.
It must be transparent to the rest of the system.
>
> I am saying that on Linux, low-power idle commonly is not transparent to the
> user, so the requirement for it to be transparent (therefor putting the
> suspend into a different category) is an Android only requirement.
>
I'm am not talking about minor latencies. If you have a platform that
for instance turns off you screen dma when entering idle, it is broken
whether is running Android or not. If it does the same in suspend it
is not a problem.
--
Arve Hj?nnev?g
On Wed, 4 Aug 2010 00:10:21 -0700
Arve Hj?nnev?g <[email protected]> wrote:
> >
> > you are stating that this must be suspend because low-power idle must be
> > transparent to the user.
>
> It must be transparent to the rest of the system.
Perhaps transparent is badly worded. Both suspend and idle are in some
way "transparent". Idle doesnt happen when an application is runnable.
Suspend is transparent in that the application can not easily detect if
it happened.
Cheers,
Flo
On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/3 <[email protected]>:
>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/3 ?<[email protected]>:
>>>>
>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>> in this case, another reason you would consider using suspend over idle
>>>> is
>>>> that you can suspend until the next timer that your privilaged
>>>> applications
>>>> have set, and skip timers set by the non-privilaged applications,
>>>> resulting
>>>> in more time asleep.
>>>
>>> Without wakelock or suspend blockers this can still break since a
>>> privileged application may be waiting on a resource held by a
>>> non-privileged application.
>>
>> since the non-privilaged application is never frozen when a privilaged
>> application is running, I'm not sure how you would get this to happen that
>> wouldn't also be a problem with wakelocks.
>
> With wakelocks we annotate that we have important work to do, until
> that work is accomplished we do not suspend. If you modify the idle
> code ignore some processes' timers the system may get stuck in idle
> while waiting for a non-privileged application to release a resource.
if you don't have a wakelock the system could go into suspend under the
exact same conditions. If the privilaged program wants to be sure of
preventing this, all it needs to do is to set of timer to take action
before the timeout.
>>
>> if you want to have a privilaged application keep the system awake while it
>> waits for a non-privilaged application, all it would need to do is to set a
>> timer near enough in the future that it's considered 'awake' all the time.
>> this will cost a context switch every timeout period (for the application to
>> check that it's still waiting and set the next timer), but that's pretty
>> cheap.
>
> No, this will kill your idle power.
you are only doing this every several seconds to prevent the system from
suspending.
it's possible that I'm making false assumptions about how quickly you want
to go into full suspend mode.
if a user is doing nothing that would warrent wakelocks, but has an
unprivilaged application running (a dancing cows game), and is doing
nothing other than occasionally hitting a button, how short is the timeout
that you would set that would have the system go into suspend? (i.e. how
frequently must the user do something to keep the system awake)
or let's use a better example, the user has an unprivilaged book-reader
application, how quickly must they change pages to prevent the system from
suspending?
I'm figuring that these times are in the 1-5 minute range.
therefor the timeout period I am mentioning above could easily be one
wakeup every 40-50 seconds.
that is not going to kill your idle power.
is my assumption about the length of the timeout incorrect?
>>
>> one thing this would destroy is the stats currently built around the
>> wakelock, but since they would be replaced by stats of exactly the type of
>> thing that powertop was written to deal with, I don't see this as a problem
>> (powertop would just have to learn a mode where it ignores the
>> non-privilaged tasks).consolodating tools is a good thing.
>>
>>>>>>> There may well be others.
>>>>>>>
>>>>>>> Whether these distinctions are a good thing or a bad thing is one of
>>>>>>> the topics of this discussion. ?But the distinctions themselves are
>>>>>>> certainly very real, from what I can see.
>>>>>>>
>>>>>>> Or am I missing your point?
>>>>>>
>>>>>> these big distinction that I see as significant seem to be in the
>>>>>> decision
>>>>>> of when to go into the different states, and the difference between the
>>>>>> states ?themselves seem to be less significant (and either very close
>>>>>> to,
>>>>>> or
>>>>>> within the variation that already exists for power saving modes)
>>>>>>
>>>>>> If I'm right bout this, then it would seem to simplify the concept and
>>>>>> change it from some really foreign android-only thing into a special
>>>>>> case
>>>>>> variation of existing core concepts.
>>>>>
>>>>> Suspend is not an android only concept. The android extensions just
>>>>> allow us to aggressively use suspend without loosing (or delaying)
>>>>> wakeup events. On the hardware that we shipped we can enter the same
>>>>> power mode from idle as we do in suspend, but we still use suspend
>>>>> primarily because it stops the monotonic clock and all the timers that
>>>>> use it. Changing suspend to behave more like an idle mode, which seems
>>>>> to be what you are suggesting, would not buy us anything.
>>>>
>>>> Ok, If I am understanding you correctly I think this is an important
>>>> point.
>>>>
>>>> What Android calls suspend is not what other linux distros call suspend,
>>>> it's just a low-power mode with different wakeup rules.
>>>>
>>>> Is this correct?
>>>>
>>>
>>> No. Android suspend is Linux suspend. We just enter it more frequently.
>>
>> In Linux, a full suspend normally takes the system down to a mode that can't
>> be reached by the normal idle mechnism (including powering down
>> peripherals). It also takes significantly different actions to wake up. What
>> you are describing seems much milder than that.
>
> We use the normal suspend sequence. The shipping hardware we have just
> don't need to do lot
>
>>
>>>> If this is the case it seems even more so that the android suspend should
>>>> be
>>>> addressed by tieing into the power management/idle stuff rather than the
>>>> suspend/hibernate side of things
>>>>
>>>> is the reason you want to stop the onotonic clock and the timers because
>>>> the
>>>> applications need to be fooled into thinking no time has passed?
>>>>
>>>
>>> Yes, but this is not an Android extension, it is part of the normal
>>> Linux suspend sequence.
>>
>> no, as noted by others in this thread, normal linux suspend/resume modifies
>> the clock to show that time has passed since the suspend happened.
>>
>
> The monotonic clock always stops. There are a few different ways to
> maintain the realtime clock and we use one of them.
>
>>>> or is it to prevent extranious wakeups?
>>>>
>>> That too.
>>
>> as noted above, this sounds like it's configurable.
>>
>>>> or is it to save additional power?
>>>>
>>> No (assuming you are asking about the clock), the actual hardware
>>> clock (on msm) stops even in idle but it is resynchronized on wakeup
>>> with a clock that never stops when used from idle.
>>
>> so I'm left not understanding the huge desire to stop the monotonic clock.
>>
>
> If you ignore the timers and don't stop the clock they are based on,
> you break a lot of apps when you resume (watchdogs and timeouts
> trigger). If you don't ignore timers, you can't sleep very long with
> existing software.
if you can stop the clocks they are based on, you could also shift them
into the future. but in any case, significant changes in time can cause
problems for suspended apps (if nothing else, broken network connections
because the machines elsewhere timed you out)
>>>>>> you have many different power saving modes, the daemon (or kernel code)
>>>>>> that
>>>>>> is determining which mode to go into would need different logic
>>>>>> (including,
>>>>>> but not limited to the ability to be able to ignore one or more cgroups
>>>>>> of
>>>>>> processes). different power saving modes have different trade-offs, and
>>>>>> some
>>>>>> of them power down different peripherals (which is always a platform
>>>>>> specific, if not system specific set of trade-offs)
>>>>>>
>>>>>
>>>>> The hardware specific idle hook can (and does) decide to go into any
>>>>> power state from idle that does not disrupt any active devices.
>>>>
>>>> This I know is an Andoid specific thing. On other platforms power states
>>>> very definantly can make user visible changes.
>>>
>>> How is this Android specific?
>>
>> you are stating that this must be suspend because low-power idle must be
>> transparent to the user.
>
> It must be transparent to the rest of the system.
>
>>
>> I am saying that on Linux, low-power idle commonly is not transparent to the
>> user, so the requirement for it to be transparent (therefor putting the
>> suspend into a different category) is an Android only requirement.
>>
>
> I'm am not talking about minor latencies. If you have a platform that
> for instance turns off you screen dma when entering idle, it is broken
> whether is running Android or not. If it does the same in suspend it
> is not a problem.
This isn't sounding quite right to me. I've seen too many discussions
about things like idle and USB devices/hubs/drives/etc getting powered
down for power savings modes to make me readily accept that everything
must be as transparent as you imply. Just the case of drive spin-down
shows that it's possible to do things that would be considered
destructive, but you have to have a flag and wake-up path to recover
within a 'reasonable' amount of time (I guess that this could be
'transparent' if that only implies that things must work eventually, which
isn't what I read into the statement)
David Lang
On Wednesday, August 04, 2010, [email protected] wrote:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
> > 2010/8/3 <[email protected]>:
> >> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>> 2010/8/3 <[email protected]>:
> >>>>
> >>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
...
> >>>>> The hardware specific idle hook can (and does) decide to go into any
> >>>>> power state from idle that does not disrupt any active devices.
> >>>>
> >>>> This I know is an Andoid specific thing. On other platforms power states
> >>>> very definantly can make user visible changes.
It would be much better if you gave specific examples. Because, for instance,
I'm not sure what platforms you have in mind.
> >>> How is this Android specific?
> >>
> >> you are stating that this must be suspend because low-power idle must be
> >> transparent to the user.
> >
> > It must be transparent to the rest of the system.
> >
> >>
> >> I am saying that on Linux, low-power idle commonly is not transparent to the
> >> user, so the requirement for it to be transparent (therefor putting the
> >> suspend into a different category) is an Android only requirement.
> >>
> >
> > I'm am not talking about minor latencies. If you have a platform that
> > for instance turns off you screen dma when entering idle, it is broken
> > whether is running Android or not. If it does the same in suspend it
> > is not a problem.
>
> This isn't sounding quite right to me. I've seen too many discussions
> about things like idle and USB devices/hubs/drives/etc getting powered
> down for power savings modes to make me readily accept that everything
> must be as transparent as you imply. Just the case of drive spin-down
> shows that it's possible to do things that would be considered
> destructive, but you have to have a flag and wake-up path to recover
> within a 'reasonable' amount of time (I guess that this could be
> 'transparent' if that only implies that things must work eventually, which
> isn't what I read into the statement)
Well, consider a single character device and suppose there is an application
talking to the driver using read(), write(), ioctl(), whatever. Now suppose
you want to put the device into a low-power state such that the device can't
do the I/O in that state. You need to ensure that the app won't be able to
reach the device while in that state and you can (1) arrange things so that
the device is put into the full-power state whenever the app tries to access
it and (2) "freeze" the app so that it won't try to access the device being in
the low-power state.
Generally speaking (1) is what idle (and any other form of runtime PM) does and
(2) is what suspend does with respect to the whole system.
In the suspend case, when you have frozen all applications, you can
sequentially disable all interrupts except for a few selected ("wakeup") ones
in a safe way. By disabling them, you ensure that the CPU will only be
"revived" by a limited set of events and that allows the system to stay
low-power for extended time intervals.
To achieve the same result in the "idle" case, you'll need to have a mechanism
to disable interrupts (except for the "wakeup" ones) avoiding synchronization
problems (eg. situations in which task A, blocked on a "suspended" device
access, holds a mutex waited for by task B that needs to run so that we can
"suspend" another device). That, however, is a difficult problem.
Thanks,
Rafael
On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
> On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
> > On Tue, 3 Aug 2010, Paul E. McKenney wrote:
> >
> >> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
> >>>
> >>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> >>>
> >>>> 2010/8/2 ?<[email protected]>:
> >>>>>
> >>>>> so what is the fundamental difference between deciding to go into
> >>>>> low-power
> >>>>> idle modes to wake up back up on a given point in the future and
> >>>>> deciding
> >>>>> that you are going to be idle for so long that you may as well suspend
> >>>>> until
> >>>>> there is user input?
> >>>>>
> >>>>
> >>>> Low power idle modes are supposed to be transparent. Suspend stops the
> >>>> monotonic clock, ignores ready threads and switches over to a separate
> >>>> set of wakeup events/interrupts. We don't suspend until there is user
> >>>> input, we suspend until there is a wakeup event (user-input, incoming
> >>>> network data/phone-calls, alarms etc..).
> >>>
> >>> s/user input/wakeup event/ and my question still stands.
> >>>
> >>> low power modes are not transparent to the user in all cases (if the
> >>> screen backlight dimms/shuts off a user reading something will
> >>> notice, if the system switches to a lower clock speed it can impact
> >>> user response time, etc) The system is making it's best guess as to
> >>> how to best srve the user by sacraficing some capibilities to save
> >>> power now so that the power can be available later.
> >>>
> >>> as I see it, suspending until a wakeup event (button press, incoming
> >>> call, alarm, etc) is just another datapoint along the same path.
> >>>
> >>> If the system could not wake itself up to respond to user input,
> >>> phone call, alarm, etc and needed the power button pressed to wake
> >>> up (or shut down to the point where the battery could be removed and
> >>> reinstalled a long time later), I would see things moving into a
> >>> different category, but as long as the system has the ability to
> >>> wake itself up later (and is still consuming power) I see the
> >>> suspend as being in the same category as the other low-power modes
> >>> (it's just more expensive to go in and out of)
> >>>
> >>>
> >>> why should the suspend be put into a different category from the
> >>> other low-power states?
> >>
> >> OK, I'll bite...
> >
> > thanks, this is not intended to be a trap.
> >
> >> From an Android perspective, the differences are as follows:
> >>
> >> 1. ? ? ?Deep idle states are entered only if there are no runnable tasks.
> >> ? ? ? ?In contrast, opportunistic suspend can happen even when there
> >> ? ? ? ?are tasks that are ready, willing, and able to run.
> >
> > Ok, this is a complication to what I'm proposing (and seems a little odd,
> > but I can see how it can work), but not neccessarily a major problem. it
> > depends on exactly how the decision is made to go into low power states
> > and/or suspend. If this is done by an application that is able to look at
> > either all activity or ignore one cgroup of processes at different times in
> > it's calculations than this would work.
> >
> >> 2. ? ? ?There can be a set of input events that do not bring the system
> >> ? ? ? ?out of suspend, but which would bring the system out of a deep
> >> ? ? ? ?idle state. ?For example, I believe that it was stated that one
> >> ? ? ? ?of the Android-based smartphones ignores touchscreen input while
> >> ? ? ? ?suspended, but pays attention to it while in deep idle states.
> >
> > I see this as simply being a matter of what devices are still enabled at the
> > different power savings levels. At one level the touchscreen is still
> > powered, while at another level it isn't, and at yet another level you have
> > to hit the power soft-button. This isn't fundamentally different from
> > powering off a USB peripheral that the system decides is idle (and then not
> > seeing input from it until something else wakes the system)
>
> The touchscreen on android devices is powered down long before we
> suspend, so that is not a good example. There is still a significant
> difference between suspend and idle though. In idle all interrupts
> work, in suspend only interrupts that the driver has called
> enable_irq_wake on will work (on platforms that support it).
>
> >> 3. ? ? ?The system comes out of a deep idle state when a timer
> >> ? ? ? ?expires. ?In contrast, timers cannot expire while the
> >> ? ? ? ?system is suspended. ?(This one is debatable: some people
> >> ? ? ? ?argue that timers are subject to jitter, and the suspend
> >> ? ? ? ?case for timers is the same as that for deep idle states,
> >> ? ? ? ?but with unbounded timer jitter. ?Others disagree. ?The
> >> ? ? ? ?resulting discussions have produced much heat, but little
> >> ? ? ? ?light. ?Such is life.)
> >
> > if you have the ability to wake for an alarm, you have the ability to wake
> > for a timer (if from no other method than to set the alarm to when the timer
> > tick would go off)
>
> If you just program the alarm you will wake up see that the monotonic
> clock has not advanced and set the alarm another n seconds into the
> future. Or are proposing that suspend should be changed to keep the
> monotonic clock running? If you are, why? We can enter the same
> hardware states from idle, and modifying suspend to wake up more often
> would increase the average power consumption in suspend, not improve
> it for idle. In other words, if suspend wakes up as often as idle, why
> use suspend?
Hmmm... The bit about the monotonic clock not advancing could help
explain at least some of the heartburn from the scheduler and real-time
folks. ;-)
My guess is that this is not a problem for Android workloads, which
probably do not contain aggressive real-time components. (With the
possible exception of interactions with the cellphone network, which
I believe are handled by a separate core with separate OS.) However,
pulling this into the Linux kernel would require that interactions with
aggressive real-time workloads be handled, one way or another.
I can see a couple possible resolutions:
1. Make OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT, so that
opportunistic suspend simply doesn't happen on systems that
support aggressive real-time workloads.
2. Allow OPPORTUNISTIC_SUSPEND and PREEMPT_RT, but suppress
opportunistic suspend when there is a user-created real-time
process. One way to handle this would be with a variation
on a tongue-in-cheek suggestion from Peter Zijlstra, namely
to have every real-time process hold a wakelock. Note that
such a wakelock would need to be held even if the real-time
process in question was not runnable, in order to meet
possible real-time deadlines when the real-time process was
awakened.
3. Your proposal here. ;-)
Thoughts?
Thanx, Paul
> >> There may well be others.
> >>
> >> Whether these distinctions are a good thing or a bad thing is one of
> >> the topics of this discussion. ?But the distinctions themselves are
> >> certainly very real, from what I can see.
> >>
> >> Or am I missing your point?
> >
> > these big distinction that I see as significant seem to be in the decision
> > of when to go into the different states, and the difference between the
> > states ?themselves seem to be less significant (and either very close to, or
> > within the variation that already exists for power saving modes)
> >
> > If I'm right bout this, then it would seem to simplify the concept and
> > change it from some really foreign android-only thing into a special case
> > variation of existing core concepts.
>
> Suspend is not an android only concept. The android extensions just
> allow us to aggressively use suspend without loosing (or delaying)
> wakeup events. On the hardware that we shipped we can enter the same
> power mode from idle as we do in suspend, but we still use suspend
> primarily because it stops the monotonic clock and all the timers that
> use it. Changing suspend to behave more like an idle mode, which seems
> to be what you are suggesting, would not buy us anything.
>
> >
> > you have many different power saving modes, the daemon (or kernel code) that
> > is determining which mode to go into would need different logic (including,
> > but not limited to the ability to be able to ignore one or more cgroups of
> > processes). different power saving modes have different trade-offs, and some
> > of them power down different peripherals (which is always a platform
> > specific, if not system specific set of trade-offs)
> >
>
> The hardware specific idle hook can (and does) decide to go into any
> power state from idle that does not disrupt any active devices.
>
> > This all depends on the ability for the code that decides to switch power
> > modes (including to trigger suspend) to be able to see things in sufficient
> > detail to be able to do different things depending on the class of programs.
> > I don't know enough about this code to know if this is the case or not, I
> > really wish that someone familiar with the power saving code could either
> > confirm that this is possible, or state that it's not possible (or at least,
> > not without major surgery)
> >
>
>
>
> --
> Arve Hj?nnev?g
On Tue, Aug 03, 2010 at 06:34:47PM -0700, Arjan van de Ven wrote:
> On Mon, 2 Aug 2010 21:56:10 -0700
> Arve Hj?nnev?g <[email protected]> wrote:
>
> > > non-obvious dependencies.
> > >
> >
> > The dependencies is what made this solution uninteresting to us. For
> > instance, we currently use cgroup scheduling to reduce the impact of
> > some background tasks, but we occasionally saw a watchdog restart of
> > the system process were critical services were waiting on a kernel
> > mutex owned by a background task for more than 20 seconds. If we froze
> > a cgroup instead, we would not hit this particular problem since tasks
> > cannot be frozen while executing kernel code the same way they can be
> > preempted, but nothing prevents a task from being frozen while holding
> > a user-space resource.
>
> one of the solutions we're looking at to solve this is to unfreeze the
> cgroup on a regular basis (say, every 15 to 30 seconds) briefly to avoid
> this kind of deadlock...
Cute!!! ;-)
If this doesn't work for the Android folks for whatever reason, another
approach would be to do the freeze in user code, which could track
whether any user-level resources (pthread mutexes, SysV semas, whatever)
where held, and do the freeze on a thread-by-thread basis within each
"victim" application as the threads reach safe points.
I must of course defer to the Android folks as to whether or not this
would actually work for Android. But if your approach works for them,
why worry?
Thanx, Paul
On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote:
> If this doesn't work for the Android folks for whatever reason, another
> approach would be to do the freeze in user code, which could track
> whether any user-level resources (pthread mutexes, SysV semas, whatever)
> where held, and do the freeze on a thread-by-thread basis within each
> "victim" application as the threads reach safe points.
The main problem I see with the cgroups solution is that it doesn't seem
to do anything to handle avoiding loss of wakeup events.
--
Matthew Garrett | [email protected]
On Tue, Aug 03, 2010 at 08:57:58PM -0700, Arjan van de Ven wrote:
> On Tue, 3 Aug 2010 17:10:15 -0700
> "Paul E. McKenney" <[email protected]> wrote:
> >
> > OK, I'll bite...
> >
> > >From an Android perspective, the differences are as follows:
> >
> > 1. Deep idle states are entered only if there are no runnable
> > tasks. In contrast, opportunistic suspend can happen even when there
> > are tasks that are ready, willing, and able to run.
>
> for "system suspend", this is an absolutely valid statement.
> for "use suspend as idle state", it's not so clearly valid.
> (but this is sort of a separate problem, basically the "when do we
> freeze the tasks that we don't like for power reasons" problem,
> which in first order is independent on what kind of idle power state
> you pick, and discussed extensively elsewhere in this thread)
>From what I can see, the Android folks are are using "suspend" in
the "system suspend" sense.
I agree that the proposals for freezing subsets of the tasks in the
system are independent of whether idle or suspend is being used.
Instead, such freezing depends on (for example) whether or not the
display is active.
That said, freezing subsets of tasks is a nice-to-have rather than a
hard requirement for Android. Though I suspect that the appearance
of a reliable way of freezing subsets of tasks just might promote
this to a hard requirement. ;-)
> > 2. There can be a set of input events that do not bring the
> > system out of suspend, but which would bring the system out of a deep
> > idle state. For example, I believe that it was stated that
> > one of the Android-based smartphones ignores touchscreen input while
> > suspended, but pays attention to it while in deep idle states.
>
> I would argue that this is both a hardware specific issue, but also a
> policy issue. From the user point of view, screen off with idle and
> screen off with suspend aren't all that different (if my phone would
> decide to idle rather than suspend because some app blocks suspend... I
> wouldn't expect a difference in behavior when I touch the screen).
> "Screen off -> don't honor touch after a bit" is almost an independent,
> but very real, policy problem (and a forced one in suspend, I'll grant
> you that). I could even argue that the policy decision "we don't care
> about the touch screen input" is a pre-condition for entering suspend
> (or in android speak, caring for touch screen input/having the touch
> screen path active would be a suspend blocker)
I agree that the subset of input events that do not bring the system out
of suspend would be governed both by hardware capabilities and by policy.
> > 3. The system comes out of a deep idle state when a timer
> > expires. In contrast, timers cannot expire while the
> > system is suspended. (This one is debatable: some people
> > argue that timers are subject to jitter, and the suspend
> > case for timers is the same as that for deep idle states,
> > but with unbounded timer jitter. Others disagree. The
> > resulting discussions have produced much heat, but little
> > light. Such is life.)
>
> I'll debate it even harder in that it's platform specific whether
> timers can get the system out of suspend or not. Clearly on the Android
> platform in question that's not the case, but for some of the Intel
> phone silicon for example, timers CAN be wake sources to get you out of
> suspend just fine. It just depend on which exact hw you talk about.
> Generally, even if the fast timers aren't wake up sources, there'll be
> some sort of alarm thing that you can pre-wake.. but yes you are right
> in saying that's rather lame.
> Either way, it's not a general property of suspend, but a property of
> suspend on the specific platform in question.
Good point, I do need to emphasize the fact that whether or not timers
pull the system out of suspend also depends both on hardware and
on policy. So I will change my statement to say something like "The
system comes out of a deep idle state when a timer expires. In contrast,
timers do not necessarily expire while the system is suspended, depending
on both hardware support and platform/application policy."
Thanx, Paul
>
>
> --
> Arjan van de Ven Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote:
>
>> If this doesn't work for the Android folks for whatever reason, another
>> approach would be to do the freeze in user code, which could track
>> whether any user-level resources (pthread mutexes, SysV semas, whatever)
>> where held, and do the freeze on a thread-by-thread basis within each
>> "victim" application as the threads reach safe points.
>
> The main problem I see with the cgroups solution is that it doesn't seem
> to do anything to handle avoiding loss of wakeup events.
there are two cgroup solutions in discussion at this point.
weeks ago there was the suggestion to put non-privilaged tasks in a cgroup
so that they could be frozen as a group. I thought the problem there was
that there can be user-space dpendancies that would prevent privilaged
tasks from working.
a couple days ago I made the suggestion to put non-privilaged tasks in a
cgroup so that the idle/suspend decision code could ignore acitivity
caused by this cgroup.
in the second version wakeup events would be 'activity' that would be
counted and therefor the system would not be idle. As for the race with
suspending and new things happening, wouldn't that be handled the same way
that it is in a normal linux box?
David Lang
On Tue, Aug 03, 2010 at 10:22:55PM -0700, Arve Hj?nnev?g wrote:
> On Tue, Aug 3, 2010 at 8:57 PM, Arjan van de Ven <[email protected]> wrote:
> > On Tue, 3 Aug 2010 17:10:15 -0700
> > "Paul E. McKenney" <[email protected]> wrote:
> >>
> >> OK, I'll bite...
> >>
> >> >From an Android perspective, the differences are as follows:
> >>
> >> 1. ? ?Deep idle states are entered only if there are no runnable
> >> tasks. In contrast, opportunistic suspend can happen even when there
> >> ? ? ? are tasks that are ready, willing, and able to run.
> >
> > for "system suspend", this is an absolutely valid statement.
> > for "use suspend as idle state", it's not so clearly valid.
> > (but this is sort of a separate problem, basically the "when do we
> > freeze the tasks that we don't like for power reasons" problem,
> > which in first order is independent on what kind of idle power state
> > you pick, and discussed extensively elsewhere in this thread)
> >
> >>
> >> 2. ? ?There can be a set of input events that do not bring the
> >> system out of suspend, but which would bring the system out of a deep
> >> ? ? ? idle state. ?For example, I believe that it was stated that
> >> one of the Android-based smartphones ignores touchscreen input while
> >> ? ? ? suspended, but pays attention to it while in deep idle states.
> >
> > I would argue that this is both a hardware specific issue, but also a
> > policy issue. From the user point of view, screen off with idle and
> > screen off with suspend aren't all that different (if my phone would
> > decide to idle rather than suspend because some app blocks suspend... I
> > wouldn't expect a difference in behavior when I touch the screen).
> > "Screen off -> don't honor touch after a bit" is almost an independent,
> > but very real, policy problem (and a forced one in suspend, I'll grant
> > you that). I could even argue that the policy decision "we don't care
> > about the touch screen input" is a pre-condition for entering suspend
> > (or in android speak, caring for touch screen input/having the touch
> > screen path active would be a suspend blocker)
> >
> >>
> >> 3. ? ?The system comes out of a deep idle state when a timer
> >> ? ? ? expires. ?In contrast, timers cannot expire while the
> >> ? ? ? system is suspended. ?(This one is debatable: some people
> >> ? ? ? argue that timers are subject to jitter, and the suspend
> >> ? ? ? case for timers is the same as that for deep idle states,
> >> ? ? ? but with unbounded timer jitter. ?Others disagree. ?The
> >> ? ? ? resulting discussions have produced much heat, but little
> >> ? ? ? light. ?Such is life.)
> >
> > I'll debate it even harder in that it's platform specific whether
> > timers can get the system out of suspend or not. Clearly on the Android
> > platform in question that's not the case, but for some of the Intel
> > phone silicon for example, timers CAN be wake sources to get you out of
> > suspend just fine. It just depend on which exact hw you talk about.
> > Generally, even if the fast timers aren't wake up sources, there'll be
> > some sort of alarm thing that you can pre-wake.. but yes you are right
> > in saying that's rather lame.
> > Either way, it's not a general property of suspend, but a property of
> > suspend on the specific platform in question.
> >
>
> I disagree. On the msm platform the low level timer that brings us out
> of the low power state is the same for idle and suspend. The
> difference is where which kernel api the request comes from. In idle,
> the next event on the clockevents device is usually the first event.
> In suspend the generic kernel timekeeping code cancels this event and
> the rtc wakeup event remains.
OK, good point. This choice of kernel APIs governs what I was calling
"policy".
Thanx, Paul
On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
> On Wednesday, August 04, 2010, [email protected] wrote:
>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/3 <[email protected]>:
>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>> 2010/8/3 <[email protected]>:
>>>>>>
>>>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> ...
>>>>>>> The hardware specific idle hook can (and does) decide to go into any
>>>>>>> power state from idle that does not disrupt any active devices.
>>>>>>
>>>>>> This I know is an Andoid specific thing. On other platforms power states
>>>>>> very definantly can make user visible changes.
>
> It would be much better if you gave specific examples. Because, for instance,
> I'm not sure what platforms you have in mind.
I gave examples in other messages that included dimming/turning off the
screen and spinning down the disk among others.
the definition of 'transparently' was then clarified to not mean
transparent to the user, but transparent (except for possibly delays) to
the applications (they may have to wait for the disk to spin up for
example)
>>>>> How is this Android specific?
>>>>
>>>> you are stating that this must be suspend because low-power idle must be
>>>> transparent to the user.
>>>
>>> It must be transparent to the rest of the system.
>>>
>>>>
>>>> I am saying that on Linux, low-power idle commonly is not transparent to the
>>>> user, so the requirement for it to be transparent (therefor putting the
>>>> suspend into a different category) is an Android only requirement.
>>>>
>>>
>>> I'm am not talking about minor latencies. If you have a platform that
>>> for instance turns off you screen dma when entering idle, it is broken
>>> whether is running Android or not. If it does the same in suspend it
>>> is not a problem.
>>
>> This isn't sounding quite right to me. I've seen too many discussions
>> about things like idle and USB devices/hubs/drives/etc getting powered
>> down for power savings modes to make me readily accept that everything
>> must be as transparent as you imply. Just the case of drive spin-down
>> shows that it's possible to do things that would be considered
>> destructive, but you have to have a flag and wake-up path to recover
>> within a 'reasonable' amount of time (I guess that this could be
>> 'transparent' if that only implies that things must work eventually, which
>> isn't what I read into the statement)
>
> Well, consider a single character device and suppose there is an application
> talking to the driver using read(), write(), ioctl(), whatever. Now suppose
> you want to put the device into a low-power state such that the device can't
> do the I/O in that state. You need to ensure that the app won't be able to
> reach the device while in that state and you can (1) arrange things so that
> the device is put into the full-power state whenever the app tries to access
> it and (2) "freeze" the app so that it won't try to access the device being in
> the low-power state.
>
> Generally speaking (1) is what idle (and any other form of runtime PM) does and
> (2) is what suspend does with respect to the whole system.
makes sense
> In the suspend case, when you have frozen all applications, you can
> sequentially disable all interrupts except for a few selected ("wakeup") ones
> in a safe way. By disabling them, you ensure that the CPU will only be
> "revived" by a limited set of events and that allows the system to stay
> low-power for extended time intervals.
the benifit of this will depend on what wakeups you are able to avoid by
putting the hardware to sleep. Depending on the hardware, this may be not
matter that much.
In addition, there are input devices like a touchscreen that could be
disabled even short of a full suspend, as long as there is some way to get
them reactivated.
> To achieve the same result in the "idle" case, you'll need to have a mechanism
> to disable interrupts (except for the "wakeup" ones) avoiding synchronization
> problems (eg. situations in which task A, blocked on a "suspended" device
> access, holds a mutex waited for by task B that needs to run so that we can
> "suspend" another device). That, however, is a difficult problem.
I would say that the difficulty of the problem depends on the hardware and
how much userspace interaction is needed. If the kernel can disable the
hardware in the driver (so that it can wake it up again when accessed by
an application) it would seem that this isn't a problem.
David Lang
On Wed, Aug 04, 2010 at 11:30:44AM -0700, [email protected] wrote:
> a couple days ago I made the suggestion to put non-privilaged tasks in a
> cgroup so that the idle/suspend decision code could ignore acitivity
> caused by this cgroup.
>
> in the second version wakeup events would be 'activity' that would be
> counted and therefor the system would not be idle. As for the race with
> suspending and new things happening, wouldn't that be handled the same
> way that it is in a normal linux box?
No! And that's precisely the issue. Android's existing behaviour could
be entirely implemented in the form of binary that manually triggers
suspend when (a) the screen is off and (b) no userspace applications
have indicated that the system shouldn't sleep, except for the wakeup
event race. Imagine the following:
1) The policy timeout is about to expire. No applications are holding
wakelocks. The system will suspend providing nothing takes a wakelock.
2) A network packet arrives indicating an incoming SIP call
3) The VOIP application takes a wakelock and prevents the phone from
suspending while the call is in progress
What stops the system going to sleep between (2) and (3)? cgroups don't,
because the voip app is an otherwise untrusted application that you've
just told the scheduler to ignore.
--
Matthew Garrett | [email protected]
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 11:30:44AM -0700, [email protected] wrote:
>> a couple days ago I made the suggestion to put non-privilaged tasks in a
>> cgroup so that the idle/suspend decision code could ignore acitivity
>> caused by this cgroup.
>>
>> in the second version wakeup events would be 'activity' that would be
>> counted and therefor the system would not be idle. As for the race with
>> suspending and new things happening, wouldn't that be handled the same
>> way that it is in a normal linux box?
>
> No! And that's precisely the issue. Android's existing behaviour could
> be entirely implemented in the form of binary that manually triggers
> suspend when (a) the screen is off and (b) no userspace applications
> have indicated that the system shouldn't sleep, except for the wakeup
> event race. Imagine the following:
>
> 1) The policy timeout is about to expire. No applications are holding
> wakelocks. The system will suspend providing nothing takes a wakelock.
> 2) A network packet arrives indicating an incoming SIP call
> 3) The VOIP application takes a wakelock and prevents the phone from
> suspending while the call is in progress
>
> What stops the system going to sleep between (2) and (3)? cgroups don't,
> because the voip app is an otherwise untrusted application that you've
> just told the scheduler to ignore.
Even in the current implementation (wakelocks), Since the VOIP application
isn't allowed to take a wakelock, wouldn't the system go to sleep
immediatly anyway, even if the application gets the packet and starts the
call? What would ever raise the wakelock to keep the phone from sleeping
in the middle of the call?
as I said last night in an e-mail to Arve
> it's possible that I'm making false assumptions about how quickly you
> want to go into full suspend mode.
>
> if a user is doing nothing that would warrent wakelocks, but has an
> unprivilaged application running (a dancing cows game), and is doing
> nothing other than occasionally hitting a button, how short is the
> timeout that you would set that would have the system go into suspend?
> (i.e. how frequently must the user do something to keep the system
> awake)
>
> or let's use a better example, the user has an unprivilaged book-reader
> application, how quickly must they change pages to prevent the system
> from suspending?
>
> I'm figuring that these times are in the 1-5 minute range.
>
> therefor the timeout period I am mentioning above could easily be one
> wakeup every 40-50 seconds. that is not going to kill your idle power.
>
> is my assumption about the length of the timeout incorrect?
David Lang
On Wed, Aug 04, 2010 at 12:15:59PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>> No! And that's precisely the issue. Android's existing behaviour could
>> be entirely implemented in the form of binary that manually triggers
>> suspend when (a) the screen is off and (b) no userspace applications
>> have indicated that the system shouldn't sleep, except for the wakeup
>> event race. Imagine the following:
>>
>> 1) The policy timeout is about to expire. No applications are holding
>> wakelocks. The system will suspend providing nothing takes a wakelock.
>> 2) A network packet arrives indicating an incoming SIP call
>> 3) The VOIP application takes a wakelock and prevents the phone from
>> suspending while the call is in progress
>>
>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>> because the voip app is an otherwise untrusted application that you've
>> just told the scheduler to ignore.
>
> Even in the current implementation (wakelocks), Since the VOIP
> application isn't allowed to take a wakelock, wouldn't the system go to
> sleep immediatly anyway, even if the application gets the packet and
> starts the call? What would ever raise the wakelock to keep the phone
> from sleeping in the middle of the call?
There's two parts of that. The first is that the voip application is
allowed to take a wakelock - but that doesn't mean that you trust it the
rest of the time.The second is that the incoming network packet causes
the kernel to take a wakelock that will be released once userspace has
processed the network packet. This ensures that at least one wakelock is
held for the entire relevant period of time.
--
Matthew Garrett | [email protected]
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 12:15:59PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>> No! And that's precisely the issue. Android's existing behaviour could
>>> be entirely implemented in the form of binary that manually triggers
>>> suspend when (a) the screen is off and (b) no userspace applications
>>> have indicated that the system shouldn't sleep, except for the wakeup
>>> event race. Imagine the following:
>>>
>>> 1) The policy timeout is about to expire. No applications are holding
>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>> 2) A network packet arrives indicating an incoming SIP call
>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>> suspending while the call is in progress
>>>
>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>> because the voip app is an otherwise untrusted application that you've
>>> just told the scheduler to ignore.
>>
>> Even in the current implementation (wakelocks), Since the VOIP
>> application isn't allowed to take a wakelock, wouldn't the system go to
>> sleep immediatly anyway, even if the application gets the packet and
>> starts the call? What would ever raise the wakelock to keep the phone
>> from sleeping in the middle of the call?
>
> There's two parts of that. The first is that the voip application is
> allowed to take a wakelock - but that doesn't mean that you trust it the
> rest of the time.
why would you trust it to take a wakelock, but not trust it the rest of
the time?
in my proposal I'm saying that if you would trust the application to take
a wakelock, you instead trust it to be sane in the rest of it's power
activity (avoiding polling, etc) and so you consider it for sleep
decisions.
> The second is that the incoming network packet causes
> the kernel to take a wakelock that will be released once userspace has
> processed the network packet. This ensures that at least one wakelock is
> held for the entire relevant period of time.
how do you determine that userspace has processed the network packet so
that the kernel can release the wakelock (or is this one of the cases
where there is a timer related to the wakelock)
two things here,
on the dirty networks that I see as common, refusing to sleep if network
packets are arriving will mean that you never go to sleep.
secondly, nothing stops the code doing the idle/suspend decision from
considering network activity. I would be surprised if there weren't
already options to support this today.
David Lang
Continuing to rush in where angels fear to tread...
This is an updated version of my list posted a couple of days ago at
http://lkml.org/lkml/2010/7/31/73. Again, this email is an attempt
to present the Android guys' requirements, based on my interpretation
of 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 discuss example mechanisms where
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.
Ducking into the nearest bunker to avoid the hailstorm of frozen fish...
Thanx, Paul
------------------------------------------------------------------------
DEFINITIONS
These have been updated based on LKML and linux-pm discussions. The names
are probably still sub-optimal, but incremental progress is nevertheless
a very good thing. I have also added a section entitled "CATEGORIES OF
APPLICATION BEHAVIOR" based on a suggestion from James Bottomley.
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
externally 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-oblivious applications" would be a
better description, which I will use until someone convinces
me otherwise.
o "PM-driving 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,
PM-driving applications seem to be those that have permission
to exert some control over the system's sleep state.
Note that an application might be power-oblivious on one Android
device and PM-driving on another, depending on whether the user
allows that application to acquire suspend blockers. The
classification might even change over time. For example, a
user might give an application PM-driving status initially,
but change his or her mind after some experience with that
application.
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
PM-driving applications that have been aggressively tuned to
reduce power consumption.
o Individual devices in an embedded system can enter "device
low-power states" when not in use.
o The system as a whole can enter a "system sleep state" when
the system as a whole is not in use. Suspend blockers are about
system sleep states rather than device low-power states.
o There was much discussion of "idle" (AKA "deep idle") and
"suspend" (as in the the current Linux-kernel suspend operations).
The following characteristics distinguish "idle" from "suspend":
1. Idle states are entered by a given CPU only there are no
runnable tasks for that CPU. In contrast, opportunistic
suspend can halt the entire system even when there
are tasks that are ready, willing, and able to run.
(But please note that this might not apply to real-time
tasks.)
Freezing of subsets of applications is somewhat related
to the idle/suspend discussion, but is covered in a
later section of this document.
2. There can be a set of input events that do not bring
the system out of suspend, but which would bring the
system out of idle. Exactly which events are in this
set depends both on hardware capabilities and on the
platform/application policy. For example, on one of
the Android-based smartphones, touchscreen input is
ignored when the system is suspended, but is handled
normally when idle.
3. The system comes out of idle when a timer expires. In
contrast, timers might or might not bring the system
out of suspend, depending on both hardware capabilities
and platform/application policy.
CATEGORIES OF APPLICATION BEHAVIOR
There are a number of categories of application behavior with respect
to power management and energy efficiency. These can be classified via
the following questions: (1) What degree of control is an application
permitted over its own behavior? (2) What degree of control is an
application permitted over the power state of individual devices within
the system? (3) What degree of control is an application permitted
over the system sleep state? (4) To what degree has the application
been tuned to reduce its power consumption, either in isolation or in
conjunction with other applications that might be running concurrently?
These categories are discussed below.
o What degree of control is an application permitted over its
own behavior?
The Linux kernel already has many controls over application
behavior:
o the CAP_ capabilities from include/linux/capability.h.
o Processes can be assigned to multiple groups, allowing
them privileged access to portions of the filesystem.
o The chroot() system call limits a process's access to the
specified subtree of the filesystem.
o The ulimit facility can limit CPU consumption, number
of processes, memory, etc. on a per-user basis. The
rlimit facility has similar effects on a per-process
basis.
o The mlockall() system call provides privileged access
to memory, avoiding page-fault overhead.
But more relevant to this discussion, real-time processes are
permitted a much higher degree of control over the timing of their
execution than are non-real-time processes. However, suspending
the system destroys any pretense of offering real-time guarantees,
which might explain much of the ire towards suspend blockers from
the real-time and scheduler folks. For but one example, Peter
Zijlstra suggested that he would merge a patch that acquired
a suspend blocker any time that the runqueues were non-empty.
My first reaction was amusement at this vintage Peter Zijlstra
response, and my second reaction was that it was a futile gesture,
as the Android guys would simply back out any such change.
After more thought, however, a variation of Peter's approach
might well be the key to resolving this tension between
real-time response on the one hand and Android's desire to
conserve power at any cost on the other. Given that suspending
destroys real-time response, why not acquire a suspend blocker
any time there is a user-created real-time task in the system,
whether runnable or not? Of course, a simpler approach would
be to make Android's OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT.
o What degree of control is an application permitted over the power
state of individual devices within the system?
Is the application in question permitted to power down the
CPU or peripheral devices? As more of the power control is
automated based on usage, it is possible that this question will
become less relevant. The longer the latency and the greater
the energy consumption of a power-up/power-down sequence for
a given device, the less suitable that device is for automatic
power-up/power-down decisions. Cache SRAMs and main-memory
DRAM tend to be less suitable for automation for this reason.
o What degree of control is an application permitted over the
system sleep state?
Is the application permitted to suspend the device? Or in the
case of Android, is the application permitted to acquire a
suspend blocker, which prevents the device from being suspended?
o To what degree has the application been tuned to reduce its
power consumption, either in isolation or in conjunction with
other applications that might be running concurrently?
See the "POWER-OPTIMIZED APPLICATIONS" section below for more
detail on the lengths that embedded developers go to in order
to conserve power -- or, more accurately, to extend battery life.
REQUIREMENTS
o Reduce the system's power consumption in order to (1) extend
battery life and (2) preserve state until external power can
be obtained.
o It is necessary to be able to use power-oblivious 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 external power or
(2) relatively undemanding laptop battery-lifetime expectations.
The system must be capable of running these power-oblivious
applications without requiring that these applications be
modified, and must be capable of reasonable power efficiency
even when power-oblivious applications are in use.
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-oblivious
applications that do not use blocking system calls.
There might well be similar requirements for other output-only
devices, as suggested by Alan Stern.
o In order to avoid overrunning hardware and/or kernel buffers,
and to minimize response latencies, designated 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 sleep state is received while the system is
transitioning into a sleep state, the system must transition
back out of the sleep state so that it can hand the user
input off to the corresponding application.
Other input events do not force a wakeup, and such input events
-can- be lost due to buffer overflow in hardware or the kernel.
Of course, the response latency to such input events can be
unbounded.
o The API must provide a way for PM-driving applications that
receive events to keep themselves running until they have been
able to process those events.
o Statistics of the power-control actions taken by PM-driving
applications must be provided. Given the current Android
implementation, the suspend blockers are manipulated via
ioctl(), so that a given application's activity can be tracked
via the suspend-blocker device, which remains open throughout
the application's lifetime. Statistics are aggregated by
name, which is passed by the application in through the
suspend-blocker interface.
o PM-driving applications can make use of power-oblivious
infrastructure. This means that a PM-driving application must
have some way, whether explicit or implicit, to ensure that
any power-oblivious infrastructure is permitted to run when a
PM-driving application needs it to run.
o If no PM-driving or power-optimized application are indicating
a need for the system to remain operating, the system is permitted
(even encouraged!) to suspend all execution, regardless of the
state of power-oblivious applications. (This requirement did
appear to be somewhat controversial, both in terms of what is
meant by "runnable" and in terms of what constitutes "execution".)
In Android, this is implemented by suspending even while
PM-driving or power-optimized applications are active, -unless-
a suspend blocker is held.
o Transition to system sleep state must be power-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 sleep 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 The API that controls the system sleep 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 sleep 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.
o Any mechanism that freezes some subset of the applications must
ensure that none of the frozen applications hold any user-level
resources, such as pthread mutexes. The reason for this is that
freezing an application that holds a shared pthread mutex will
result in an application-level hang should some unfrozen process
attempt to acquire that same pthread mutex. Note that although
the current cgroup freezer ensures that frozen applications do not
hold any kernel-level mutexes (at least assuming these mutexes
are not wrongly held when returning to user-level execution),
it currently does nothing to prevent freezing processes holding
pthread mutexes. (There are some proposals to address this issue.)
NICE-TO-HAVES
o It would be nice to be able to identify power-oblivious
applications that never were depended on by PM-driving
applications. This particular class of power-oblivious
applications could be shut down when the screen blanks even
if some PM-driving application was preventing the system from
powering down.
There are two obstacles to meeting this requirement:
1. There must be a reliable way to identify such
applications. This should be doable, for example the
application might be tagged by its developer.
2. There must be a reliable way to freeze them such
that no frozen application holds a resource that
might be contended by a non-frozen application.
Although the cgroup freezer does ensure that frozen
tasks hold no kernel-level resources, it currently does
nothing to ensure that no user-level resources are held.
There are some alternative proposals, which might or
might not be more successful.
o Any initialization of the API that controls the system power
state should be unconditional, so as to be free from failure.
Such unconditional initialization reduces the intrusiveness of
the Android patchset.
APPARENT NON-REQUIREMENTS
o Transitioning to system sleep 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.)
That said, it should not be hard to provide a highly scalable
implementation of suspend blockers, especially if large systems
are allowed to take their time suspending themselves.
o Conserving power in the WiFi and cellular telephony networks.
At the moment, the focus is on increased battery life in the
handheld device, perhaps even at the expense of additional
power consumed by the externally powered WiFi and cell-telephony
equipment.
o Synchronizing wakeups of unrelated applications. This is of
course an important requirement for power savings overall, but
seems to be left to other mechanisms (e.g., timer aggregation)
by the Android folks. (One can argue that suspend blockers will
aggregate timers after a sufficiently long suspension, but they
would not necessarily stay aggregated during the wakeup period
without some other mechanism helping out.)
SUGGESTED USAGE
These are constraints that the developer is expected to abide by,
"for best results" and all that.
o When a PM-driving application is preventing the system from
shutting down, and is also waiting on a power-oblivious
application, the PM-driving application should set a timeout
to handle the possibility that the power-oblivious application
might halt or otherwise fail.
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 sleep 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 achieve 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. Provide "heartbeat" services that allow applications to
synchronize with each other. This seems most applicable for
applications that run infrequently, such as email-checking and
location-service applications.
5. 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.
6. 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 PM-driving (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-oblivious 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.
ACKNOWLEDGMENTS
Of course, just because I acknowledge their contributions does
not necessarily mean that I think they agree with my assessment
of the requirements behind suspend blockers. ;-)
Nevertheless, I am grateful for any and all feedback, whatever
the form of that feedback might be. I am new to this area, and
have much to learn.
Alan Stern
Arjan van de Ven
Arve Hj?nnev?g
David Brownell
David Lang
Florian Mickler
James Bottomley
Mikael Abrahamsson
Olivier Galibert
Paul Menage
Rafael J. Wysocki
Ted Ts'o
On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
> why would you trust it to take a wakelock, but not trust it the rest of
> the time?
Because I trust that when the application author says "I explicitly need
the machine to stay awake" that they mean it, whereas I don't trust the
application author to write an application that avoids consuming
background CPU. The distinction is pretty important.
> in my proposal I'm saying that if you would trust the application to take
> a wakelock, you instead trust it to be sane in the rest of it's power
> activity (avoiding polling, etc) and so you consider it for sleep
> decisions.
When we say "trust", we're not using the same meaning as we do with
security. Yes, it's possible that an application that can block suspend
will do so at inopportune times. But given that blocking suspend is an
explicit act it's much more likely that the developer will only use it
in reasonable ways, while it's still entirely plausible that the
application will generate unnecessary wakeups. Pretending otherwise is
unrealistic. I recently had to fix the fact that the kernel IPMI layer
would generate a constant 1000 wakeups a second even if it had an
interrupt-driven controller or was entirely idle.
>> The second is that the incoming network packet causes
>> the kernel to take a wakelock that will be released once userspace has
>> processed the network packet. This ensures that at least one wakelock is
>> held for the entire relevant period of time.
>
> how do you determine that userspace has processed the network packet so
> that the kernel can release the wakelock (or is this one of the cases
> where there is a timer related to the wakelock)
The current implementation uses a timer, but Rafael's implementation
should allow userspace to explicitly acknowledge it.
> two things here,
>
> on the dirty networks that I see as common, refusing to sleep if network
> packets are arriving will mean that you never go to sleep.
Cell networks typically have no background traffic, for obvious reasons.
> secondly, nothing stops the code doing the idle/suspend decision from
> considering network activity. I would be surprised if there weren't
> already options to support this today.
If you proxy every potential wakeup event through some central server
then this becomes much easier, but it's also a performance hit. The
alternative is that you poll for network activity, but that's a power
hit.
--
Matthew Garrett | [email protected]
On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>
> >On Wed, Aug 04, 2010 at 12:15:59PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>No! And that's precisely the issue. Android's existing behaviour could
> >>>be entirely implemented in the form of binary that manually triggers
> >>>suspend when (a) the screen is off and (b) no userspace applications
> >>>have indicated that the system shouldn't sleep, except for the wakeup
> >>>event race. Imagine the following:
> >>>
> >>>1) The policy timeout is about to expire. No applications are holding
> >>>wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>2) A network packet arrives indicating an incoming SIP call
> >>>3) The VOIP application takes a wakelock and prevents the phone from
> >>>suspending while the call is in progress
> >>>
> >>>What stops the system going to sleep between (2) and (3)? cgroups don't,
> >>>because the voip app is an otherwise untrusted application that you've
> >>>just told the scheduler to ignore.
> >>
> >>Even in the current implementation (wakelocks), Since the VOIP
> >>application isn't allowed to take a wakelock, wouldn't the system go to
> >>sleep immediatly anyway, even if the application gets the packet and
> >>starts the call? What would ever raise the wakelock to keep the phone
> >>from sleeping in the middle of the call?
> >
> >There's two parts of that. The first is that the voip application is
> >allowed to take a wakelock - but that doesn't mean that you trust it the
> >rest of the time.
>
> why would you trust it to take a wakelock, but not trust it the rest
> of the time?
>
> in my proposal I'm saying that if you would trust the application to
> take a wakelock, you instead trust it to be sane in the rest of it's
> power activity (avoiding polling, etc) and so you consider it for
> sleep decisions.
The word "trust" does not appear to be helping here. ;-)
The VOIP application acquires a suspend blocker when it needs to prevent
the system from suspending, and releases that suspend blocker when it
can tolerate the system suspending. It is important to note that while
the VOIP application holds the suspend blocker, the system won't suspend
even if it is completely idle (for example, if the VOIP application uses
blocking system calls, during the time that the VOIP application is
waiting for its next event).
> >The second is that the incoming network packet causes
> >the kernel to take a wakelock that will be released once userspace has
> >processed the network packet. This ensures that at least one wakelock is
> >held for the entire relevant period of time.
>
> how do you determine that userspace has processed the network packet
> so that the kernel can release the wakelock (or is this one of the
> cases where there is a timer related to the wakelock)
There are two cases:
1. The application is permitted to acquire suspend blockers.
In this case, the application would acquire a suspend blocker
before reading the input. It would then read the input (at
which point the kernel releases its suspend blocker), do any
needed processing, and finally release the suspend blocker.
So in this case, the system knows that the application is
done processing the input when that application releases
its suspend blocker.
2. The application is prohibited from acquiring suspend blockers.
In this case, the system might well be suspended before the
application has a chance to do more than read the input.
But the application will get a chance to process the input
when the next input event is directed to it.
> two things here,
>
> on the dirty networks that I see as common, refusing to sleep if
> network packets are arriving will mean that you never go to sleep.
>
> secondly, nothing stops the code doing the idle/suspend decision
> from considering network activity. I would be surprised if there
> weren't already options to support this today.
I don't know about the general networking case for Android, but the
example of downloading was discussed some time back. The application
doing the download acquires a suspend blocker, which it releases once
the download is complete (or once a timeout expires, if I remember
correctly). In this particular case, the network packets were not
bringing the device out of suspend.
There might well be other cases where networking packets -do- bring
the system out of suspend, but I must leave this to someone who knows
more about Android than do I.
Thanx, Paul
On Wednesday, August 04, 2010, [email protected] wrote:
> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>
> > On Wednesday, August 04, 2010, [email protected] wrote:
> >> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>> 2010/8/3 <[email protected]>:
> >>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> >>>>
> >>>>> 2010/8/3 <[email protected]>:
> >>>>>>
> >>>>>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> > ...
> >>>>>>> The hardware specific idle hook can (and does) decide to go into any
> >>>>>>> power state from idle that does not disrupt any active devices.
> >>>>>>
> >>>>>> This I know is an Andoid specific thing. On other platforms power states
> >>>>>> very definantly can make user visible changes.
> >
> > It would be much better if you gave specific examples. Because, for instance,
> > I'm not sure what platforms you have in mind.
>
> I gave examples in other messages that included dimming/turning off the
> screen and spinning down the disk among others.
>
> the definition of 'transparently' was then clarified to not mean
> transparent to the user, but transparent (except for possibly delays) to
> the applications (they may have to wait for the disk to spin up for
> example)
>
> >>>>> How is this Android specific?
> >>>>
> >>>> you are stating that this must be suspend because low-power idle must be
> >>>> transparent to the user.
> >>>
> >>> It must be transparent to the rest of the system.
> >>>
> >>>>
> >>>> I am saying that on Linux, low-power idle commonly is not transparent to the
> >>>> user, so the requirement for it to be transparent (therefor putting the
> >>>> suspend into a different category) is an Android only requirement.
> >>>>
> >>>
> >>> I'm am not talking about minor latencies. If you have a platform that
> >>> for instance turns off you screen dma when entering idle, it is broken
> >>> whether is running Android or not. If it does the same in suspend it
> >>> is not a problem.
> >>
> >> This isn't sounding quite right to me. I've seen too many discussions
> >> about things like idle and USB devices/hubs/drives/etc getting powered
> >> down for power savings modes to make me readily accept that everything
> >> must be as transparent as you imply. Just the case of drive spin-down
> >> shows that it's possible to do things that would be considered
> >> destructive, but you have to have a flag and wake-up path to recover
> >> within a 'reasonable' amount of time (I guess that this could be
> >> 'transparent' if that only implies that things must work eventually, which
> >> isn't what I read into the statement)
> >
> > Well, consider a single character device and suppose there is an application
> > talking to the driver using read(), write(), ioctl(), whatever. Now suppose
> > you want to put the device into a low-power state such that the device can't
> > do the I/O in that state. You need to ensure that the app won't be able to
> > reach the device while in that state and you can (1) arrange things so that
> > the device is put into the full-power state whenever the app tries to access
> > it and (2) "freeze" the app so that it won't try to access the device being in
> > the low-power state.
> >
> > Generally speaking (1) is what idle (and any other form of runtime PM) does and
> > (2) is what suspend does with respect to the whole system.
>
> makes sense
>
> > In the suspend case, when you have frozen all applications, you can
> > sequentially disable all interrupts except for a few selected ("wakeup") ones
> > in a safe way. By disabling them, you ensure that the CPU will only be
> > "revived" by a limited set of events and that allows the system to stay
> > low-power for extended time intervals.
>
> the benifit of this will depend on what wakeups you are able to avoid by
> putting the hardware to sleep. Depending on the hardware, this may be not
> matter that much.
That's correct, but evidently it does make a difference with the hardware
Android commonly runs on.
> In addition, there are input devices like a touchscreen that could be
> disabled even short of a full suspend, as long as there is some way to get
> them reactivated.
That's correct again, but it doesn't matter too much as far as the difference
between "deep idle" and suspend is concerned. These devices are generally not
the interrupt sources that are difficult to shut down safely in the "idle" case.
> > To achieve the same result in the "idle" case, you'll need to have a mechanism
> > to disable interrupts (except for the "wakeup" ones) avoiding synchronization
> > problems (eg. situations in which task A, blocked on a "suspended" device
> > access, holds a mutex waited for by task B that needs to run so that we can
> > "suspend" another device). That, however, is a difficult problem.
>
> I would say that the difficulty of the problem depends on the hardware and
> how much userspace interaction is needed. If the kernel can disable the
> hardware in the driver (so that it can wake it up again when accessed by
> an application) it would seem that this isn't a problem.
Well, I guess it's useful to consider the sequence of events in the "idle"
case.
We first detect that a CPU is idle, so it can be put into a C-state (or
equivalent). It's easy to put that CPU into such a state, but suppose we
want to do more and put all devices into low-power states at that point.
We have to ensure that there are no devices in the middle of DMA and that
the other CPUs are idle (that's kind of easy, but still). Next, we have to
figure out the right ordering in which to put devices into low-power states
(that is not trivial, because the tasks that use those devices may depend on
each other in various ways). If we decide to shut down clock source
interrupts, we must ensure that the timekeeping will be correct after that and
so on. Moreover, things get ugly if there are shared interrupts.
Suspend kind of works around these difficulties by taking the entire user
space out of the picture with one big sledgehammer called the freezer,
but these problems would have to be actually _solved_ in the "idle" case.
Thanks,
Rafael
Hi!
> > If this doesn't work for the Android folks for whatever reason, another
> > approach would be to do the freeze in user code, which could track
> > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > where held, and do the freeze on a thread-by-thread basis within each
> > "victim" application as the threads reach safe points.
>
> The main problem I see with the cgroups solution is that it doesn't seem
> to do anything to handle avoiding loss of wakeup events.
In different message, Arve said they are actually using low-power idle
to emulate suspend on Android.
This came like a bit of a shock to me ("why do they make it so complex
then"), but... it also means that as soon as you are able to stop
"unwanted" processing, you can just leave normal cpuidle mechanisms to
deal with the rest...
(Of course, you'll also have to fix kernel timers not to beat
unneccessarily often; still that's better solution that just stoping
them all and then sprinkling wakelocks all over the kernel to deal
with obvious bugs it introduces...)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wednesday, August 04, 2010, Paul E. McKenney wrote:
> On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hj?nnev?g wrote:
> > On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
> > > On Tue, 3 Aug 2010, Paul E. McKenney wrote:
> > >
> > >> On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
> > >>>
> > >>> On Tue, 3 Aug 2010, Arve Hj?nnev?g wrote:
> > >>>
> > >>>> 2010/8/2 <[email protected]>:
> > >>>>>
> > >>>>> so what is the fundamental difference between deciding to go into
> > >>>>> low-power
> > >>>>> idle modes to wake up back up on a given point in the future and
> > >>>>> deciding
> > >>>>> that you are going to be idle for so long that you may as well suspend
> > >>>>> until
> > >>>>> there is user input?
> > >>>>>
> > >>>>
> > >>>> Low power idle modes are supposed to be transparent. Suspend stops the
> > >>>> monotonic clock, ignores ready threads and switches over to a separate
> > >>>> set of wakeup events/interrupts. We don't suspend until there is user
> > >>>> input, we suspend until there is a wakeup event (user-input, incoming
> > >>>> network data/phone-calls, alarms etc..).
> > >>>
> > >>> s/user input/wakeup event/ and my question still stands.
> > >>>
> > >>> low power modes are not transparent to the user in all cases (if the
> > >>> screen backlight dimms/shuts off a user reading something will
> > >>> notice, if the system switches to a lower clock speed it can impact
> > >>> user response time, etc) The system is making it's best guess as to
> > >>> how to best srve the user by sacraficing some capibilities to save
> > >>> power now so that the power can be available later.
> > >>>
> > >>> as I see it, suspending until a wakeup event (button press, incoming
> > >>> call, alarm, etc) is just another datapoint along the same path.
> > >>>
> > >>> If the system could not wake itself up to respond to user input,
> > >>> phone call, alarm, etc and needed the power button pressed to wake
> > >>> up (or shut down to the point where the battery could be removed and
> > >>> reinstalled a long time later), I would see things moving into a
> > >>> different category, but as long as the system has the ability to
> > >>> wake itself up later (and is still consuming power) I see the
> > >>> suspend as being in the same category as the other low-power modes
> > >>> (it's just more expensive to go in and out of)
> > >>>
> > >>>
> > >>> why should the suspend be put into a different category from the
> > >>> other low-power states?
> > >>
> > >> OK, I'll bite...
> > >
> > > thanks, this is not intended to be a trap.
> > >
> > >> From an Android perspective, the differences are as follows:
> > >>
> > >> 1. Deep idle states are entered only if there are no runnable tasks.
> > >> In contrast, opportunistic suspend can happen even when there
> > >> are tasks that are ready, willing, and able to run.
> > >
> > > Ok, this is a complication to what I'm proposing (and seems a little odd,
> > > but I can see how it can work), but not neccessarily a major problem. it
> > > depends on exactly how the decision is made to go into low power states
> > > and/or suspend. If this is done by an application that is able to look at
> > > either all activity or ignore one cgroup of processes at different times in
> > > it's calculations than this would work.
> > >
> > >> 2. There can be a set of input events that do not bring the system
> > >> out of suspend, but which would bring the system out of a deep
> > >> idle state. For example, I believe that it was stated that one
> > >> of the Android-based smartphones ignores touchscreen input while
> > >> suspended, but pays attention to it while in deep idle states.
> > >
> > > I see this as simply being a matter of what devices are still enabled at the
> > > different power savings levels. At one level the touchscreen is still
> > > powered, while at another level it isn't, and at yet another level you have
> > > to hit the power soft-button. This isn't fundamentally different from
> > > powering off a USB peripheral that the system decides is idle (and then not
> > > seeing input from it until something else wakes the system)
> >
> > The touchscreen on android devices is powered down long before we
> > suspend, so that is not a good example. There is still a significant
> > difference between suspend and idle though. In idle all interrupts
> > work, in suspend only interrupts that the driver has called
> > enable_irq_wake on will work (on platforms that support it).
> >
> > >> 3. The system comes out of a deep idle state when a timer
> > >> expires. In contrast, timers cannot expire while the
> > >> system is suspended. (This one is debatable: some people
> > >> argue that timers are subject to jitter, and the suspend
> > >> case for timers is the same as that for deep idle states,
> > >> but with unbounded timer jitter. Others disagree. The
> > >> resulting discussions have produced much heat, but little
> > >> light. Such is life.)
> > >
> > > if you have the ability to wake for an alarm, you have the ability to wake
> > > for a timer (if from no other method than to set the alarm to when the timer
> > > tick would go off)
> >
> > If you just program the alarm you will wake up see that the monotonic
> > clock has not advanced and set the alarm another n seconds into the
> > future. Or are proposing that suspend should be changed to keep the
> > monotonic clock running? If you are, why? We can enter the same
> > hardware states from idle, and modifying suspend to wake up more often
> > would increase the average power consumption in suspend, not improve
> > it for idle. In other words, if suspend wakes up as often as idle, why
> > use suspend?
>
> Hmmm... The bit about the monotonic clock not advancing could help
> explain at least some of the heartburn from the scheduler and real-time
> folks. ;-)
I think that indeed is the case, although they haven't expressed that directly
yet (at least not that I know of :-)).
> My guess is that this is not a problem for Android workloads, which
> probably do not contain aggressive real-time components. (With the
> possible exception of interactions with the cellphone network, which
> I believe are handled by a separate core with separate OS.) However,
> pulling this into the Linux kernel would require that interactions with
> aggressive real-time workloads be handled, one way or another.
>
> I can see a couple possible resolutions:
>
> 1. Make OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT, so that
> opportunistic suspend simply doesn't happen on systems that
> support aggressive real-time workloads.
>
> 2. Allow OPPORTUNISTIC_SUSPEND and PREEMPT_RT, but suppress
> opportunistic suspend when there is a user-created real-time
> process. One way to handle this would be with a variation
> on a tongue-in-cheek suggestion from Peter Zijlstra, namely
> to have every real-time process hold a wakelock. Note that
> such a wakelock would need to be held even if the real-time
> process in question was not runnable, in order to meet
> possible real-time deadlines when the real-time process was
> awakened.
I guess the scheduler itself would need to hold that wakelock.
> 3. Your proposal here. ;-)
>
> Thoughts?
The case when there's a real-time process that's not using its time slices
(because it doesn't have anything to do) seems to be hard. You'd probably
want to suspend in that case, but then meeting the real-time deadlines would
be kind of unrealistic ...
Thanks,
Rafael
On Wednesday, August 04, 2010, Paul E. McKenney wrote:
> On Tue, Aug 03, 2010 at 08:57:58PM -0700, Arjan van de Ven wrote:
> > On Tue, 3 Aug 2010 17:10:15 -0700
> > "Paul E. McKenney" <[email protected]> wrote:
> > >
> > > OK, I'll bite...
> > >
> > > >From an Android perspective, the differences are as follows:
> > >
> > > 1. Deep idle states are entered only if there are no runnable
> > > tasks. In contrast, opportunistic suspend can happen even when there
> > > are tasks that are ready, willing, and able to run.
> >
> > for "system suspend", this is an absolutely valid statement.
> > for "use suspend as idle state", it's not so clearly valid.
> > (but this is sort of a separate problem, basically the "when do we
> > freeze the tasks that we don't like for power reasons" problem,
> > which in first order is independent on what kind of idle power state
> > you pick, and discussed extensively elsewhere in this thread)
>
> From what I can see, the Android folks are are using "suspend" in
> the "system suspend" sense.
>
> I agree that the proposals for freezing subsets of the tasks in the
> system are independent of whether idle or suspend is being used.
> Instead, such freezing depends on (for example) whether or not the
> display is active.
>
> That said, freezing subsets of tasks is a nice-to-have rather than a
> hard requirement for Android. Though I suspect that the appearance
> of a reliable way of freezing subsets of tasks just might promote
> this to a hard requirement. ;-)
>
> > > 2. There can be a set of input events that do not bring the
> > > system out of suspend, but which would bring the system out of a deep
> > > idle state. For example, I believe that it was stated that
> > > one of the Android-based smartphones ignores touchscreen input while
> > > suspended, but pays attention to it while in deep idle states.
> >
> > I would argue that this is both a hardware specific issue, but also a
> > policy issue. From the user point of view, screen off with idle and
> > screen off with suspend aren't all that different (if my phone would
> > decide to idle rather than suspend because some app blocks suspend... I
> > wouldn't expect a difference in behavior when I touch the screen).
> > "Screen off -> don't honor touch after a bit" is almost an independent,
> > but very real, policy problem (and a forced one in suspend, I'll grant
> > you that). I could even argue that the policy decision "we don't care
> > about the touch screen input" is a pre-condition for entering suspend
> > (or in android speak, caring for touch screen input/having the touch
> > screen path active would be a suspend blocker)
>
> I agree that the subset of input events that do not bring the system out
> of suspend would be governed both by hardware capabilities and by policy.
>
> > > 3. The system comes out of a deep idle state when a timer
> > > expires. In contrast, timers cannot expire while the
> > > system is suspended. (This one is debatable: some people
> > > argue that timers are subject to jitter, and the suspend
> > > case for timers is the same as that for deep idle states,
> > > but with unbounded timer jitter. Others disagree. The
> > > resulting discussions have produced much heat, but little
> > > light. Such is life.)
> >
> > I'll debate it even harder in that it's platform specific whether
> > timers can get the system out of suspend or not. Clearly on the Android
> > platform in question that's not the case, but for some of the Intel
> > phone silicon for example, timers CAN be wake sources to get you out of
> > suspend just fine. It just depend on which exact hw you talk about.
> > Generally, even if the fast timers aren't wake up sources, there'll be
> > some sort of alarm thing that you can pre-wake.. but yes you are right
> > in saying that's rather lame.
> > Either way, it's not a general property of suspend, but a property of
> > suspend on the specific platform in question.
>
> Good point, I do need to emphasize the fact that whether or not timers
> pull the system out of suspend also depends both on hardware and
> on policy. So I will change my statement to say something like "The
> system comes out of a deep idle state when a timer expires. In contrast,
> timers do not necessarily expire while the system is suspended, depending
> on both hardware support and platform/application policy."
That's correct IMO.
Thanks,
Rafael
On Wed, Aug 04, 2010 at 10:42:08PM +0200, Pavel Machek wrote:
> This came like a bit of a shock to me ("why do they make it so complex
> then"), but... it also means that as soon as you are able to stop
> "unwanted" processing, you can just leave normal cpuidle mechanisms to
> deal with the rest...
How do you differentiate between "unwanted" and "wanted" processing in
the same task in a race-free manner?
--
Matthew Garrett | [email protected]
On Wed, Aug 04, 2010 at 10:42:08PM +0200, Pavel Machek wrote:
> Hi!
>
> > > If this doesn't work for the Android folks for whatever reason, another
> > > approach would be to do the freeze in user code, which could track
> > > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > > where held, and do the freeze on a thread-by-thread basis within each
> > > "victim" application as the threads reach safe points.
> >
> > The main problem I see with the cgroups solution is that it doesn't seem
> > to do anything to handle avoiding loss of wakeup events.
>
> In different message, Arve said they are actually using low-power idle
> to emulate suspend on Android.
Hello, Pavel,
Could you please point me at this message?
Thanx, Paul
> This came like a bit of a shock to me ("why do they make it so complex
> then"), but... it also means that as soon as you are able to stop
> "unwanted" processing, you can just leave normal cpuidle mechanisms to
> deal with the rest...
>
> (Of course, you'll also have to fix kernel timers not to beat
> unneccessarily often; still that's better solution that just stoping
> them all and then sprinkling wakelocks all over the kernel to deal
> with obvious bugs it introduces...)
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wednesday, August 04, 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 11:30:44AM -0700, [email protected] wrote:
> > a couple days ago I made the suggestion to put non-privilaged tasks in a
> > cgroup so that the idle/suspend decision code could ignore acitivity
> > caused by this cgroup.
> >
> > in the second version wakeup events would be 'activity' that would be
> > counted and therefor the system would not be idle. As for the race with
> > suspending and new things happening, wouldn't that be handled the same
> > way that it is in a normal linux box?
>
> No! And that's precisely the issue. Android's existing behaviour could
> be entirely implemented in the form of binary that manually triggers
> suspend when (a) the screen is off and (b) no userspace applications
> have indicated that the system shouldn't sleep, except for the wakeup
> event race. Imagine the following:
>
> 1) The policy timeout is about to expire. No applications are holding
> wakelocks. The system will suspend providing nothing takes a wakelock.
> 2) A network packet arrives indicating an incoming SIP call
> 3) The VOIP application takes a wakelock and prevents the phone from
> suspending while the call is in progress
>
> What stops the system going to sleep between (2) and (3)? cgroups don't,
> because the voip app is an otherwise untrusted application that you've
> just told the scheduler to ignore.
I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
avoid the race (if pm_wakeup_event() is called at 2)).
Thanks,
Rafael
On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> > No! And that's precisely the issue. Android's existing behaviour could
> > be entirely implemented in the form of binary that manually triggers
> > suspend when (a) the screen is off and (b) no userspace applications
> > have indicated that the system shouldn't sleep, except for the wakeup
> > event race. Imagine the following:
> >
> > 1) The policy timeout is about to expire. No applications are holding
> > wakelocks. The system will suspend providing nothing takes a wakelock.
> > 2) A network packet arrives indicating an incoming SIP call
> > 3) The VOIP application takes a wakelock and prevents the phone from
> > suspending while the call is in progress
> >
> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> > because the voip app is an otherwise untrusted application that you've
> > just told the scheduler to ignore.
>
> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> avoid the race (if pm_wakeup_event() is called at 2)).
Yes, I think that solves the problem. The only question then is whether
it's preferable to use cgroups or suspend fully, which is pretty much up
to the implementation. In other words, is there a reason we're still
having this conversation? :) It'd be good to have some feedback from
Google as to whether this satisfies their functional requirements.
--
Matthew Garrett | [email protected]
On Wed, Aug 04, 2010 at 09:56:55PM +0100, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, August 04, 2010, Matthew Garrett wrote:
> > > No! And that's precisely the issue. Android's existing behaviour could
> > > be entirely implemented in the form of binary that manually triggers
> > > suspend when (a) the screen is off and (b) no userspace applications
> > > have indicated that the system shouldn't sleep, except for the wakeup
> > > event race. Imagine the following:
> > >
> > > 1) The policy timeout is about to expire. No applications are holding
> > > wakelocks. The system will suspend providing nothing takes a wakelock.
> > > 2) A network packet arrives indicating an incoming SIP call
> > > 3) The VOIP application takes a wakelock and prevents the phone from
> > > suspending while the call is in progress
> > >
> > > What stops the system going to sleep between (2) and (3)? cgroups don't,
> > > because the voip app is an otherwise untrusted application that you've
> > > just told the scheduler to ignore.
> >
> > I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> > avoid the race (if pm_wakeup_event() is called at 2)).
>
> Yes, I think that solves the problem. The only question then is whether
> it's preferable to use cgroups or suspend fully, which is pretty much up
> to the implementation. In other words, is there a reason we're still
> having this conversation? :) It'd be good to have some feedback from
> Google as to whether this satisfies their functional requirements.
The issue with cgroup freezer as currently defined is that it can freeze
processes that hold user-level resources (pthread mutexes, SysV semas,
...). If some non-frozen process attempts to acquire that resource, you
get a hang. There might be some ways to work around this, for example,
Arjan suggests momentarily unfreezing periodically, and I suggested doing
the freeze in user-space code, but we don't know if either of these will
really do what is required.
Also, I believe that Android's use of cgroups would be in addition to
suspending fully rather than instead of. Freezing a subset of the
applications allows cutting power drain from output-only apps when
the screen blanks but where some app such as a download needs to keep
the system active. They still would need to suspend once the download
completes.
But we do need to hear from the Android guys on these points.
Thanx, Paul
Hi!
> > > > If this doesn't work for the Android folks for whatever reason, another
> > > > approach would be to do the freeze in user code, which could track
> > > > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > > > where held, and do the freeze on a thread-by-thread basis within each
> > > > "victim" application as the threads reach safe points.
> > >
> > > The main problem I see with the cgroups solution is that it doesn't seem
> > > to do anything to handle avoiding loss of wakeup events.
> >
> > In different message, Arve said they are actually using low-power idle
> > to emulate suspend on Android.
>
> Hello, Pavel,
>
> Could you please point me at this message?
AFAICT, this tells us that idle and suspend is the same hardware state
on current Android hardware:
Pavel
Message-ID: <[email protected]>
Arve said:
If you just program the alarm you will wake up see that the monotonic
clock has not advanced and set the alarm another n seconds into the
future. Or are proposing that suspend should be changed to keep the
monotonic clock running? If you are, why? We can enter the same
hardware states from idle, and modifying suspend to wake up more often
would increase the average power consumption in suspend, not improve
it for idle. In other words, if suspend wakes up as often as idle, why
use suspend?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wednesday, August 04, 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 09:56:55PM +0100, Matthew Garrett wrote:
> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, August 04, 2010, Matthew Garrett wrote:
> > > > No! And that's precisely the issue. Android's existing behaviour could
> > > > be entirely implemented in the form of binary that manually triggers
> > > > suspend when (a) the screen is off and (b) no userspace applications
> > > > have indicated that the system shouldn't sleep, except for the wakeup
> > > > event race. Imagine the following:
> > > >
> > > > 1) The policy timeout is about to expire. No applications are holding
> > > > wakelocks. The system will suspend providing nothing takes a wakelock.
> > > > 2) A network packet arrives indicating an incoming SIP call
> > > > 3) The VOIP application takes a wakelock and prevents the phone from
> > > > suspending while the call is in progress
> > > >
> > > > What stops the system going to sleep between (2) and (3)? cgroups don't,
> > > > because the voip app is an otherwise untrusted application that you've
> > > > just told the scheduler to ignore.
> > >
> > > I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> > > avoid the race (if pm_wakeup_event() is called at 2)).
> >
> > Yes, I think that solves the problem. The only question then is whether
> > it's preferable to use cgroups or suspend fully, which is pretty much up
> > to the implementation. In other words, is there a reason we're still
> > having this conversation? :) It'd be good to have some feedback from
> > Google as to whether this satisfies their functional requirements.
>
> The issue with cgroup freezer as currently defined is that it can freeze
> processes that hold user-level resources (pthread mutexes, SysV semas,
> ...). If some non-frozen process attempts to acquire that resource, you
> get a hang. There might be some ways to work around this, for example,
> Arjan suggests momentarily unfreezing periodically, and I suggested doing
> the freeze in user-space code, but we don't know if either of these will
> really do what is required.
>
> Also, I believe that Android's use of cgroups would be in addition to
> suspending fully rather than instead of. Freezing a subset of the
> applications allows cutting power drain from output-only apps when
> the screen blanks but where some app such as a download needs to keep
> the system active. They still would need to suspend once the download
> completes.
One can argue that once the download has been completed, the cpuidle framework
should make the system reduce its energy consumption to the level achievable
by using suspend.
However, the problem is the cpuidle framework only deals with CPUs right
now (at least generally) and there's a problem of the interrupt sources that
allow the monotonic clock to advance and are deactivated during suspend
(which allows more energy to be saved, because periodic timers are then
effectively disabled).
So, it seems, system suspend is necessary to maximize energy savings
as long as the cpuidle framework cannot take care of I/O devices and interrupt
sources in general.
Thanks,
Rafael
On Wed, 4 Aug 2010 23:15:13 +0200
Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > > > If this doesn't work for the Android folks for whatever reason, another
> > > > > approach would be to do the freeze in user code, which could track
> > > > > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > > > > where held, and do the freeze on a thread-by-thread basis within each
> > > > > "victim" application as the threads reach safe points.
> > > >
> > > > The main problem I see with the cgroups solution is that it doesn't seem
> > > > to do anything to handle avoiding loss of wakeup events.
> > >
> > > In different message, Arve said they are actually using low-power idle
> > > to emulate suspend on Android.
> >
> > Hello, Pavel,
> >
> > Could you please point me at this message?
>
> AFAICT, this tells us that idle and suspend is the same hardware state
> on current Android hardware:
> Pavel
>
> Message-ID: <[email protected]>
>
> Arve said:
>
> If you just program the alarm you will wake up see that the monotonic
> clock has not advanced and set the alarm another n seconds into the
> future. Or are proposing that suspend should be changed to keep the
> monotonic clock running? If you are, why? We can enter the same
> hardware states from idle, and modifying suspend to wake up more often
> would increase the average power consumption in suspend, not improve
> it for idle. In other words, if suspend wakes up as often as idle, why
> use suspend?
>
>
They always told us from the beginning, that on the msm platform they
reach the same powerlevel from suspend and idle. They still get gains
from using opportunistic suspend.
Cheers,
Flo
On Wed, Aug 04, 2010 at 11:15:13PM +0200, Pavel Machek wrote:
> > > In different message, Arve said they are actually using low-power idle
> > > to emulate suspend on Android.
> > Could you please point me at this message?
> AFAICT, this tells us that idle and suspend is the same hardware state
> on current Android hardware:
This is all massively system dependant. On some systems when the system
is in the same idle state in the lowest power idle mode as in suspend
however as a result of not doing the suspend (which causes Linux to
quiesce most of the hardware) many more things will be able to generate
wake events. On other systems you will achieve a lower power state by
using suspend for various reasons, some fixable and some not. I rather
suspect Arve was talking about the former case.
On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>> > No! And that's precisely the issue. Android's existing behaviour could
>> > be entirely implemented in the form of binary that manually triggers
>> > suspend when (a) the screen is off and (b) no userspace applications
>> > have indicated that the system shouldn't sleep, except for the wakeup
>> > event race. Imagine the following:
>> >
>> > 1) The policy timeout is about to expire. No applications are holding
>> > wakelocks. The system will suspend providing nothing takes a wakelock.
>> > 2) A network packet arrives indicating an incoming SIP call
>> > 3) The VOIP application takes a wakelock and prevents the phone from
>> > suspending while the call is in progress
>> >
>> > What stops the system going to sleep between (2) and (3)? cgroups don't,
>> > because the voip app is an otherwise untrusted application that you've
>> > just told the scheduler to ignore.
>>
>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
>> avoid the race (if pm_wakeup_event() is called at 2)).
>
> Yes, I think that solves the problem. The only question then is whether
How? By passing a timeout to pm_wakeup_event when the network driver
gets the packet or by passing 0. If you pass a timeout it is the same
as using a wakelock with a timeout and should work (assuming the
timeout you picked is long enough). If you don't pass a timeout it
does not work, since the packet may not be visible to user-space yet.
> it's preferable to use cgroups or suspend fully, which is pretty much up
> to the implementation. In other words, is there a reason we're still
I have seen no proposed way to use cgroups that will work. If you
leave some processes running while other processes are frozen you run
into problems when a frozen process holds a resource that a running
process needs.
> having this conversation? :) It'd be good to have some feedback from
> Google as to whether this satisfies their functional requirements.
>
That is "this"? The merged code? If so, no it does not satisfy our
requirements. The in kernel api, while offering similar functionality
to the wakelock interface, does not use any handles which makes it
impossible to get reasonable stats (You don't know which pm_stay_awake
request pm_relax is reverting). The proposed in user-space interface
of calling into every process that receives wakeup events before every
suspend call is also not compatible with existing apps.
--
Arve Hj?nnev?g
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
>
>> why would you trust it to take a wakelock, but not trust it the rest of
>> the time?
>
> Because I trust that when the application author says "I explicitly need
> the machine to stay awake" that they mean it, whereas I don't trust the
> application author to write an application that avoids consuming
> background CPU. The distinction is pretty important.
on the other hand, making an application avoid consuming inappropriate
background resources helps everywhere. an explicit "don't let the machine
sleep" only works if you are trusted by a system that implements this
flag.
yes, it is painful to make the change, but the end result is better (and
there are more tools out there to figure things out)
>> in my proposal I'm saying that if you would trust the application to take
>> a wakelock, you instead trust it to be sane in the rest of it's power
>> activity (avoiding polling, etc) and so you consider it for sleep
>> decisions.
>
> When we say "trust", we're not using the same meaning as we do with
> security. Yes, it's possible that an application that can block suspend
> will do so at inopportune times. But given that blocking suspend is an
> explicit act it's much more likely that the developer will only use it
> in reasonable ways, while it's still entirely plausible that the
> application will generate unnecessary wakeups. Pretending otherwise is
> unrealistic. I recently had to fix the fact that the kernel IPMI layer
> would generate a constant 1000 wakeups a second even if it had an
> interrupt-driven controller or was entirely idle.
I'm not sure I buy the distinction, but I'm not a maintainer so it's
others you have to convince.
it's better to have one type of problem with one set of tools that
document why the machine isn't sleeping, than to have orthoginal ways of
influencing power management.
but if you have an application in the mid-level trust situation, go ahead
and have it talk to a 'keepalive' daemon that is in the 'trusted' set and
let the rest of the app run untrusted. As I noted elsewhere, the keepalive
daemon would need very little in the way of resources and can implement
much more complex policies than anyone is going to be willing to put in
the kernel.
>>> The second is that the incoming network packet causes
>>> the kernel to take a wakelock that will be released once userspace has
>>> processed the network packet. This ensures that at least one wakelock is
>>> held for the entire relevant period of time.
>>
>> how do you determine that userspace has processed the network packet so
>> that the kernel can release the wakelock (or is this one of the cases
>> where there is a timer related to the wakelock)
>
> The current implementation uses a timer, but Rafael's implementation
> should allow userspace to explicitly acknowledge it.
similar to the current implementation, the arrival of a packet could be
counted as activity that keeps the system awake for a bit (your timeout)
>> two things here,
>>
>> on the dirty networks that I see as common, refusing to sleep if network
>> packets are arriving will mean that you never go to sleep.
>
> Cell networks typically have no background traffic, for obvious reasons.
but don't most new smartphones also connect up to wifi networks? those are
FAR from quiet.
>> secondly, nothing stops the code doing the idle/suspend decision from
>> considering network activity. I would be surprised if there weren't
>> already options to support this today.
>
> If you proxy every potential wakeup event through some central server
> then this becomes much easier, but it's also a performance hit. The
> alternative is that you poll for network activity, but that's a power
> hit.
I'm not suggesting running all events through some central server (unless
you count the kernel as that server), I'm saying that the decision that
the system is idle and therefor can be stopped should be able to take this
infomation into account, and if there's a race here, it should be a race
that exists everywhere else, so there should be a general solution, not
something specific to one use-case. (and definantly not something that
requires all software to be modified and trusted to implement)
David Lang
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>
>>> On Wed, Aug 04, 2010 at 12:15:59PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>>> be entirely implemented in the form of binary that manually triggers
>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>>> event race. Imagine the following:
>>>>>
>>>>> 1) The policy timeout is about to expire. No applications are holding
>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>> suspending while the call is in progress
>>>>>
>>>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>>>> because the voip app is an otherwise untrusted application that you've
>>>>> just told the scheduler to ignore.
>>>>
>>>> Even in the current implementation (wakelocks), Since the VOIP
>>>> application isn't allowed to take a wakelock, wouldn't the system go to
>>>> sleep immediatly anyway, even if the application gets the packet and
>>>> starts the call? What would ever raise the wakelock to keep the phone
>>>> from sleeping in the middle of the call?
>>>
>>> There's two parts of that. The first is that the voip application is
>>> allowed to take a wakelock - but that doesn't mean that you trust it the
>>> rest of the time.
>>
>> why would you trust it to take a wakelock, but not trust it the rest
>> of the time?
>>
>> in my proposal I'm saying that if you would trust the application to
>> take a wakelock, you instead trust it to be sane in the rest of it's
>> power activity (avoiding polling, etc) and so you consider it for
>> sleep decisions.
>
> The word "trust" does not appear to be helping here. ;-)
>
> The VOIP application acquires a suspend blocker when it needs to prevent
> the system from suspending, and releases that suspend blocker when it
> can tolerate the system suspending. It is important to note that while
> the VOIP application holds the suspend blocker, the system won't suspend
> even if it is completely idle (for example, if the VOIP application uses
> blocking system calls, during the time that the VOIP application is
> waiting for its next event).
In the terminology I have been using, the VOIP sofware is then trusted to
take the wakelock appropriately, and I'm then saying it would be in the
trusted cgroup
>>> The second is that the incoming network packet causes
>>> the kernel to take a wakelock that will be released once userspace has
>>> processed the network packet. This ensures that at least one wakelock is
>>> held for the entire relevant period of time.
>>
>> how do you determine that userspace has processed the network packet
>> so that the kernel can release the wakelock (or is this one of the
>> cases where there is a timer related to the wakelock)
>
> There are two cases:
>
> 1. The application is permitted to acquire suspend blockers.
> In this case, the application would acquire a suspend blocker
> before reading the input. It would then read the input (at
> which point the kernel releases its suspend blocker), do any
> needed processing, and finally release the suspend blocker.
>
> So in this case, the system knows that the application is
> done processing the input when that application releases
> its suspend blocker.
in my proposal, the application is trusted to take the wakelock, so it
would be trusted to not use the CPU wildly inappropriatly and so it
running would make the system active and so it would not sleep.
> 2. The application is prohibited from acquiring suspend blockers.
> In this case, the system might well be suspended before the
> application has a chance to do more than read the input.
>
> But the application will get a chance to process the input
> when the next input event is directed to it.
In this case the system would go ahead and suspend, but the next time the
sustem wakes up for any reason, this application would continue to run and
process the input
>> two things here,
>>
>> on the dirty networks that I see as common, refusing to sleep if
>> network packets are arriving will mean that you never go to sleep.
>>
>> secondly, nothing stops the code doing the idle/suspend decision
>> from considering network activity. I would be surprised if there
>> weren't already options to support this today.
>
> I don't know about the general networking case for Android, but the
> example of downloading was discussed some time back. The application
> doing the download acquires a suspend blocker, which it releases once
> the download is complete (or once a timeout expires, if I remember
> correctly). In this particular case, the network packets were not
> bringing the device out of suspend.
it would seem reasonable to say that if a packet arrives for an existing
connection (which the kernel does know) it is considered activity for
purposes of sleeping.
I don't know if you would care enough to try and say that packets for
untrusted apps network connections don't keep the system awake, or just
allow them to (after all, keypresses going to untrusted apps do keep the
system awake)
> There might well be other cases where networking packets -do- bring
> the system out of suspend, but I must leave this to someone who knows
> more about Android than do I.
this would be the normal wake-on-lan type of functionality that exists
without Android.
The primary thing that I was getting at was the other things above.
David Lang
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>> No! And that's precisely the issue. Android's existing behaviour could
>>> be entirely implemented in the form of binary that manually triggers
>>> suspend when (a) the screen is off and (b) no userspace applications
>>> have indicated that the system shouldn't sleep, except for the wakeup
>>> event race. Imagine the following:
>>>
>>> 1) The policy timeout is about to expire. No applications are holding
>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>> 2) A network packet arrives indicating an incoming SIP call
>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>> suspending while the call is in progress
>>>
>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>> because the voip app is an otherwise untrusted application that you've
>>> just told the scheduler to ignore.
>>
>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
>> avoid the race (if pm_wakeup_event() is called at 2)).
>
> Yes, I think that solves the problem. The only question then is whether
> it's preferable to use cgroups or suspend fully, which is pretty much up
> to the implementation. In other words, is there a reason we're still
> having this conversation? :) It'd be good to have some feedback from
> Google as to whether this satisfies their functional requirements.
the proposal that I nade was not to use cgroups to freeze some processes
and not others, but to use cgroups to decide to ignore some processes when
deciding if the system is idle, stop everything or nothing. cgroups are
just a way of easily grouping processes (and their children) into
different groups.
David Lang
On Wed, 4 Aug 2010, Florian Mickler wrote:
> On Wed, 4 Aug 2010 23:15:13 +0200
> Pavel Machek <[email protected]> wrote:
>
>> Hi!
>>
>>>>>> If this doesn't work for the Android folks for whatever reason, another
>>>>>> approach would be to do the freeze in user code, which could track
>>>>>> whether any user-level resources (pthread mutexes, SysV semas, whatever)
>>>>>> where held, and do the freeze on a thread-by-thread basis within each
>>>>>> "victim" application as the threads reach safe points.
>>>>>
>>>>> The main problem I see with the cgroups solution is that it doesn't seem
>>>>> to do anything to handle avoiding loss of wakeup events.
>>>>
>>>> In different message, Arve said they are actually using low-power idle
>>>> to emulate suspend on Android.
>>>
>>> Hello, Pavel,
>>>
>>> Could you please point me at this message?
>>
>> AFAICT, this tells us that idle and suspend is the same hardware state
>> on current Android hardware:
>> Pavel
>>
>> Message-ID: <[email protected]>
>>
>> Arve said:
>>
>> If you just program the alarm you will wake up see that the monotonic
>> clock has not advanced and set the alarm another n seconds into the
>> future. Or are proposing that suspend should be changed to keep the
>> monotonic clock running? If you are, why? We can enter the same
>> hardware states from idle, and modifying suspend to wake up more often
>> would increase the average power consumption in suspend, not improve
>> it for idle. In other words, if suspend wakes up as often as idle, why
>> use suspend?
>>
>>
>
> They always told us from the beginning, that on the msm platform they
> reach the same powerlevel from suspend and idle. They still get gains
> from using opportunistic suspend.
Yes, you will always get gains if you shutdown while there is still work
to do.
the question I am raising is.
If, instead of doing opportunistic suspend (with wakelocks to keep things
awake, requiring explicit application code changes to implement), how
close would you be able to get if instead you just were able to tell the
system to ignore some processes when considering if the system can sleep
or not?
With badly written 'trusted' apps you will have poor power useage, but
with badly written apps grabbing wakelocks inappropriately you will have
poor power useage.
David Lang
On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>
>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>
>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>
>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>> be entirely implemented in the form of binary that manually triggers
>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>> event race. Imagine the following:
>>>>
>>>> 1) The policy timeout is about to expire. No applications are holding
>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>> 2) A network packet arrives indicating an incoming SIP call
>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>> suspending while the call is in progress
>>>>
>>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>>> because the voip app is an otherwise untrusted application that you've
>>>> just told the scheduler to ignore.
>>>
>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
>>> to
>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>
>> Yes, I think that solves the problem. The only question then is whether
>> it's preferable to use cgroups or suspend fully, which is pretty much up
>> to the implementation. In other words, is there a reason we're still
>> having this conversation? :) It'd be good to have some feedback from
>> Google as to whether this satisfies their functional requirements.
>
> the proposal that I nade was not to use cgroups to freeze some processes and
> not others, but to use cgroups to decide to ignore some processes when
> deciding if the system is idle, stop everything or nothing. cgroups are just
> a way of easily grouping processes (and their children) into different
> groups.
>
That does not avoid the dependency problem. A process may be waiting
on a resource that a process you ignore owns. I you ignore the process
that owns the resource and enter idle when it is ready to run (or
waiting on a timer), you are still effectively blocking the other
process.
--
Arve Hj?nnev?g
On Wed, 4 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 10:42:08PM +0200, Pavel Machek wrote:
>
>> This came like a bit of a shock to me ("why do they make it so complex
>> then"), but... it also means that as soon as you are able to stop
>> "unwanted" processing, you can just leave normal cpuidle mechanisms to
>> deal with the rest...
>
> How do you differentiate between "unwanted" and "wanted" processing in
> the same task in a race-free manner?
how much do you care? (not from a theoretical point of view, but from a
practical point of view, how much difference does it make)
how much "unwanted" processing would you allow a process to do before
shutting down?
how likely are apps that you would trust to just assert "I know better
than the system or the user how important I am, don't you dare sleep now"
that do this properly, but then do other processing that you really don't
want to have happen? (I expect that if the authors of those apps ever ran
into this case, they would just add another wakelock to prevent it)
If the only things you have running are apps that are trusted to take the
wakelock, are you really going to sleep any more frequently with the
wakelock infrastructure than you would with just idle detection? (this can
be tested today by just stubbing out the wakelock checks so they have no
effect on sleeping)
David Lang
On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>
>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>
>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>
>>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>>> be entirely implemented in the form of binary that manually triggers
>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>>> event race. Imagine the following:
>>>>>
>>>>> 1) The policy timeout is about to expire. No applications are holding
>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>> suspending while the call is in progress
>>>>>
>>>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>>>> because the voip app is an otherwise untrusted application that you've
>>>>> just told the scheduler to ignore.
>>>>
>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
>>>> to
>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>
>>> Yes, I think that solves the problem. The only question then is whether
>>> it's preferable to use cgroups or suspend fully, which is pretty much up
>>> to the implementation. In other words, is there a reason we're still
>>> having this conversation? :) It'd be good to have some feedback from
>>> Google as to whether this satisfies their functional requirements.
>>
>> the proposal that I nade was not to use cgroups to freeze some processes and
>> not others, but to use cgroups to decide to ignore some processes when
>> deciding if the system is idle, stop everything or nothing. cgroups are just
>> a way of easily grouping processes (and their children) into different
>> groups.
>>
>
> That does not avoid the dependency problem. A process may be waiting
> on a resource that a process you ignore owns. I you ignore the process
> that owns the resource and enter idle when it is ready to run (or
> waiting on a timer), you are still effectively blocking the other
> process.
and if you don't have a wakelock the same thing will happen. If you expect
the process to take a while you can set a timeout to wake up every 30
seconds or so and wait again, this would be enough to prevent you from
going to sleep (or am I misunderstanding how long before you go into
suspend without a wakelock set, see my other e-mail for the full question)
David Lang
On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
> Subject: Re: Attempted summary of suspend-blockers LKML thread
>
> On Wednesday, August 04, 2010, [email protected] wrote:
>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>> In the suspend case, when you have frozen all applications, you can
>>> sequentially disable all interrupts except for a few selected ("wakeup") ones
>>> in a safe way. By disabling them, you ensure that the CPU will only be
>>> "revived" by a limited set of events and that allows the system to stay
>>> low-power for extended time intervals.
>>
>> the benifit of this will depend on what wakeups you are able to avoid by
>> putting the hardware to sleep. Depending on the hardware, this may be not
>> matter that much.
>
> That's correct, but evidently it does make a difference with the hardware
> Android commonly runs on.
Ok, but is there a way to put some of this to sleep without involving a
full suspend?
>> In addition, there are input devices like a touchscreen that could be
>> disabled even short of a full suspend, as long as there is some way to get
>> them reactivated.
>
> That's correct again, but it doesn't matter too much as far as the difference
> between "deep idle" and suspend is concerned. These devices are generally not
> the interrupt sources that are difficult to shut down safely in the "idle" case.
>
>>> To achieve the same result in the "idle" case, you'll need to have a mechanism
>>> to disable interrupts (except for the "wakeup" ones) avoiding synchronization
>>> problems (eg. situations in which task A, blocked on a "suspended" device
>>> access, holds a mutex waited for by task B that needs to run so that we can
>>> "suspend" another device). That, however, is a difficult problem.
>>
>> I would say that the difficulty of the problem depends on the hardware and
>> how much userspace interaction is needed. If the kernel can disable the
>> hardware in the driver (so that it can wake it up again when accessed by
>> an application) it would seem that this isn't a problem.
>
> Well, I guess it's useful to consider the sequence of events in the "idle"
> case.
>
> We first detect that a CPU is idle, so it can be put into a C-state (or
> equivalent). It's easy to put that CPU into such a state, but suppose we
> want to do more and put all devices into low-power states at that point.
> We have to ensure that there are no devices in the middle of DMA and that
> the other CPUs are idle (that's kind of easy, but still). Next, we have to
> figure out the right ordering in which to put devices into low-power states
> (that is not trivial, because the tasks that use those devices may depend on
> each other in various ways). If we decide to shut down clock source
> interrupts, we must ensure that the timekeeping will be correct after that and
> so on. Moreover, things get ugly if there are shared interrupts.
>
> Suspend kind of works around these difficulties by taking the entire user
> space out of the picture with one big sledgehammer called the freezer,
> but these problems would have to be actually _solved_ in the "idle" case.
I'm not opposed to doing a suspend if the system is idle enough, I'm just
questioning if suspend is really that different, or if it can be viewed as
yet another low power mode (one that's significantly more expensive to
transition in and out of)
David Lang
On Wed, Aug 04, 2010 at 03:29:25PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>On Wed, Aug 04, 2010 at 12:15:59PM -0700, [email protected] wrote:
> >>>>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>>>No! And that's precisely the issue. Android's existing behaviour could
> >>>>>be entirely implemented in the form of binary that manually triggers
> >>>>>suspend when (a) the screen is off and (b) no userspace applications
> >>>>>have indicated that the system shouldn't sleep, except for the wakeup
> >>>>>event race. Imagine the following:
> >>>>>
> >>>>>1) The policy timeout is about to expire. No applications are holding
> >>>>>wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>>>2) A network packet arrives indicating an incoming SIP call
> >>>>>3) The VOIP application takes a wakelock and prevents the phone from
> >>>>>suspending while the call is in progress
> >>>>>
> >>>>>What stops the system going to sleep between (2) and (3)? cgroups don't,
> >>>>>because the voip app is an otherwise untrusted application that you've
> >>>>>just told the scheduler to ignore.
> >>>>
> >>>>Even in the current implementation (wakelocks), Since the VOIP
> >>>>application isn't allowed to take a wakelock, wouldn't the system go to
> >>>>sleep immediatly anyway, even if the application gets the packet and
> >>>>starts the call? What would ever raise the wakelock to keep the phone
> >>>>from sleeping in the middle of the call?
> >>>
> >>>There's two parts of that. The first is that the voip application is
> >>>allowed to take a wakelock - but that doesn't mean that you trust it the
> >>>rest of the time.
> >>
> >>why would you trust it to take a wakelock, but not trust it the rest
> >>of the time?
> >>
> >>in my proposal I'm saying that if you would trust the application to
> >>take a wakelock, you instead trust it to be sane in the rest of it's
> >>power activity (avoiding polling, etc) and so you consider it for
> >>sleep decisions.
> >
> >The word "trust" does not appear to be helping here. ;-)
> >
> >The VOIP application acquires a suspend blocker when it needs to prevent
> >the system from suspending, and releases that suspend blocker when it
> >can tolerate the system suspending. It is important to note that while
> >the VOIP application holds the suspend blocker, the system won't suspend
> >even if it is completely idle (for example, if the VOIP application uses
> >blocking system calls, during the time that the VOIP application is
> >waiting for its next event).
>
> In the terminology I have been using, the VOIP sofware is then
> trusted to take the wakelock appropriately, and I'm then saying it
> would be in the trusted cgroup
Understood, but...
> >>>The second is that the incoming network packet causes
> >>>the kernel to take a wakelock that will be released once userspace has
> >>>processed the network packet. This ensures that at least one wakelock is
> >>>held for the entire relevant period of time.
> >>
> >>how do you determine that userspace has processed the network packet
> >>so that the kernel can release the wakelock (or is this one of the
> >>cases where there is a timer related to the wakelock)
> >
> >There are two cases:
> >
> >1. The application is permitted to acquire suspend blockers.
> > In this case, the application would acquire a suspend blocker
> > before reading the input. It would then read the input (at
> > which point the kernel releases its suspend blocker), do any
> > needed processing, and finally release the suspend blocker.
> >
> > So in this case, the system knows that the application is
> > done processing the input when that application releases
> > its suspend blocker.
>
> in my proposal, the application is trusted to take the wakelock, so
> it would be trusted to not use the CPU wildly inappropriatly and so
> it running would make the system active and so it would not sleep.
... here you seem to be assuming that "trusted to properly use a wakelock"
implies "coded to optimize power usage when not holding a wakelock."
But this does not necessarily follow.
> >2. The application is prohibited from acquiring suspend blockers.
> > In this case, the system might well be suspended before the
> > application has a chance to do more than read the input.
> >
> > But the application will get a chance to process the input
> > when the next input event is directed to it.
>
> In this case the system would go ahead and suspend, but the next
> time the sustem wakes up for any reason, this application would
> continue to run and process the input
Yep, that is in fact what I said. ;-)
> >>two things here,
> >>
> >>on the dirty networks that I see as common, refusing to sleep if
> >>network packets are arriving will mean that you never go to sleep.
> >>
> >>secondly, nothing stops the code doing the idle/suspend decision
> >>from considering network activity. I would be surprised if there
> >>weren't already options to support this today.
> >
> >I don't know about the general networking case for Android, but the
> >example of downloading was discussed some time back. The application
> >doing the download acquires a suspend blocker, which it releases once
> >the download is complete (or once a timeout expires, if I remember
> >correctly). In this particular case, the network packets were not
> >bringing the device out of suspend.
>
> it would seem reasonable to say that if a packet arrives for an
> existing connection (which the kernel does know) it is considered
> activity for purposes of sleeping.
That would be up to the people creating the system in question. In
some cases, they might (as you say) want every packet arriving to
wake up the system, in other cases they might not. We should not
be taking that design decision away from them.
> I don't know if you would care enough to try and say that packets
> for untrusted apps network connections don't keep the system awake,
> or just allow them to (after all, keypresses going to untrusted apps
> do keep the system awake)
Again, this is up to the people creating the system in question. On
some Android systems, there is a particular button you have to press
to wake the system up after it has suspended itself.
> >There might well be other cases where networking packets -do- bring
> >the system out of suspend, but I must leave this to someone who knows
> >more about Android than do I.
>
> this would be the normal wake-on-lan type of functionality that
> exists without Android.
Although this wake-on-LAN functionality applies only to special
wake-up packets, not to normal packets, right?
Thanx, Paul
> The primary thing that I was getting at was the other things above.
>
> David Lang
On Wed, Aug 04, 2010 at 03:56:42PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
> >On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
> >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>
> >>>On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >>>>
> >>>>On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >>>>>
> >>>>>No! And that's precisely the issue. Android's existing behaviour could
> >>>>>be entirely implemented in the form of binary that manually triggers
> >>>>>suspend when (a) the screen is off and (b) no userspace applications
> >>>>>have indicated that the system shouldn't sleep, except for the wakeup
> >>>>>event race. Imagine the following:
> >>>>>
> >>>>>1) The policy timeout is about to expire. No applications are holding
> >>>>>wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>>>2) A network packet arrives indicating an incoming SIP call
> >>>>>3) The VOIP application takes a wakelock and prevents the phone from
> >>>>>suspending while the call is in progress
> >>>>>
> >>>>>What stops the system going to sleep between (2) and (3)? cgroups don't,
> >>>>>because the voip app is an otherwise untrusted application that you've
> >>>>>just told the scheduler to ignore.
> >>>>
> >>>>I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
> >>>>to
> >>>>avoid the race (if pm_wakeup_event() is called at 2)).
> >>>
> >>>Yes, I think that solves the problem. The only question then is whether
> >>>it's preferable to use cgroups or suspend fully, which is pretty much up
> >>>to the implementation. In other words, is there a reason we're still
> >>>having this conversation? :) It'd be good to have some feedback from
> >>>Google as to whether this satisfies their functional requirements.
> >>
> >>the proposal that I nade was not to use cgroups to freeze some processes and
> >>not others, but to use cgroups to decide to ignore some processes when
> >>deciding if the system is idle, stop everything or nothing. cgroups are just
> >>a way of easily grouping processes (and their children) into different
> >>groups.
> >
> >That does not avoid the dependency problem. A process may be waiting
> >on a resource that a process you ignore owns. I you ignore the process
> >that owns the resource and enter idle when it is ready to run (or
> >waiting on a timer), you are still effectively blocking the other
> >process.
>
> and if you don't have a wakelock the same thing will happen. If you
> expect the process to take a while you can set a timeout to wake up
> every 30 seconds or so and wait again, this would be enough to
> prevent you from going to sleep (or am I misunderstanding how long
> before you go into suspend without a wakelock set, see my other
> e-mail for the full question)
The difference between the Android scheme and your proposal is that the
Android scheme freezes -all- the processes, not just a subset of them.
Therefore, in the Android scheme, the case of one process attempting to
acquire a resource held by a frozen process. In contrast, any scheme
that attempts to freeze only a subset of the processes must somehow
either avoid or properly handle the situation where a frozen process is
holding a resource that a running process is trying to acquire.
Thanx, Paul
One suggestion: Get an Android Phone, test your ideas on it, then comment.
2010/8/4 <[email protected]>:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
>> On Wed, Aug 4, 2010 at 3:31 PM, ?<[email protected]> wrote:
>>>
>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>
>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>>
>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>>
>>>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>>>> be entirely implemented in the form of binary that manually triggers
>>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>>>> event race. Imagine the following:
>>>>>>
>>>>>> 1) The policy timeout is about to expire. No applications are holding
>>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>>> suspending while the call is in progress
>>>>>>
>>>>>> What stops the system going to sleep between (2) and (3)? cgroups
>>>>>> don't,
>>>>>> because the voip app is an otherwise untrusted application that you've
>>>>>> just told the scheduler to ignore.
>>>>>
>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
>>>>> to
>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>>
>>>> Yes, I think that solves the problem. The only question then is whether
>>>> it's preferable to use cgroups or suspend fully, which is pretty much up
>>>> to the implementation. In other words, is there a reason we're still
>>>> having this conversation? :) It'd be good to have some feedback from
>>>> Google as to whether this satisfies their functional requirements.
>>>
>>> the proposal that I nade was not to use cgroups to freeze some processes
>>> and
>>> not others, but to use cgroups to decide to ignore some processes when
>>> deciding if the system is idle, stop everything or nothing. cgroups are
>>> just
>>> a way of easily grouping processes (and their children) into different
>>> groups.
>>>
>>
>> That does not avoid the dependency problem. A process may be waiting
>> on a resource that a process you ignore owns. I you ignore the process
>> that owns the resource and enter idle when it is ready to run (or
>> waiting on a timer), you are still effectively blocking the other
>> process.
>
> and if you don't have a wakelock the same thing will happen. If you expect
Not the same thing. If you don't hold a wakelock the entire system
will suspend and when it wakes up it continues where it left off.
Timeout still have time left before they expire.
> the process to take a while you can set a timeout to wake up every 30
> seconds or so and wait again, this would be enough to prevent you from going
I don't think polling is an acceptable solution to this problem. You
user space code know needs to know what "idle" timeout you have
selected so it can choose a faster poll rate. When is it safe to stop
polling?
> to sleep (or am I misunderstanding how long before you go into suspend
> without a wakelock set, see my other e-mail for the full question)
>
We suspend as soon as no wakelocks are held. There is no delay.
--
Arve Hj?nnev?g
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 03:29:25PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>> On Wed, Aug 04, 2010 at 12:29:36PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>>
>>>>> There's two parts of that. The first is that the voip application is
>>>>> allowed to take a wakelock - but that doesn't mean that you trust it the
>>>>> rest of the time.
>>>>
>>>> why would you trust it to take a wakelock, but not trust it the rest
>>>> of the time?
>>>>
>>>> in my proposal I'm saying that if you would trust the application to
>>>> take a wakelock, you instead trust it to be sane in the rest of it's
>>>> power activity (avoiding polling, etc) and so you consider it for
>>>> sleep decisions.
>>>
>>> The word "trust" does not appear to be helping here. ;-)
>>>
>>> The VOIP application acquires a suspend blocker when it needs to prevent
>>> the system from suspending, and releases that suspend blocker when it
>>> can tolerate the system suspending. It is important to note that while
>>> the VOIP application holds the suspend blocker, the system won't suspend
>>> even if it is completely idle (for example, if the VOIP application uses
>>> blocking system calls, during the time that the VOIP application is
>>> waiting for its next event).
>>
>> In the terminology I have been using, the VOIP sofware is then
>> trusted to take the wakelock appropriately, and I'm then saying it
>> would be in the trusted cgroup
>
> Understood, but...
>
>> it would be trusted to not use the CPU wildly inappropriatly and so
>> it running would make the system active and so it would not sleep.
>
> ... here you seem to be assuming that "trusted to properly use a wakelock"
> implies "coded to optimize power usage when not holding a wakelock."
> But this does not necessarily follow.
I am saying that 'trusted to use a wakelock' does imply 'trusted to not
waste power'
I am sure that there are apps that do not manage power effectivly, but I
don't expect that giving those same developers wakelock power will make
them do much better. I expect that any time they discover the system going
to sleep on them, they will just add another wakelock to keep it awake. If
they were the type to carefully consider what was really important and
what wasn't, I would expect them to write fairly power efficiant code in
the first place.
>>> 2. The application is prohibited from acquiring suspend blockers.
>>> In this case, the system might well be suspended before the
>>> application has a chance to do more than read the input.
>>>
>>> But the application will get a chance to process the input
>>> when the next input event is directed to it.
>>
>> In this case the system would go ahead and suspend, but the next
>> time the sustem wakes up for any reason, this application would
>> continue to run and process the input
>
> Yep, that is in fact what I said. ;-)
so the systems are pretty much equivalent from this point of view.
>>>> two things here,
>>>>
>>>> on the dirty networks that I see as common, refusing to sleep if
>>>> network packets are arriving will mean that you never go to sleep.
>>>>
>>>> secondly, nothing stops the code doing the idle/suspend decision
>>>> from considering network activity. I would be surprised if there
>>>> weren't already options to support this today.
>>>
>>> I don't know about the general networking case for Android, but the
>>> example of downloading was discussed some time back. The application
>>> doing the download acquires a suspend blocker, which it releases once
>>> the download is complete (or once a timeout expires, if I remember
>>> correctly). In this particular case, the network packets were not
>>> bringing the device out of suspend.
>>
>> it would seem reasonable to say that if a packet arrives for an
>> existing connection (which the kernel does know) it is considered
>> activity for purposes of sleeping.
>
> That would be up to the people creating the system in question. In
> some cases, they might (as you say) want every packet arriving to
> wake up the system, in other cases they might not. We should not
> be taking that design decision away from them.
well, if you have the kernel take a wakelock when the packet arrives, you
are doing the equivalent thing.
>> I don't know if you would care enough to try and say that packets
>> for untrusted apps network connections don't keep the system awake,
>> or just allow them to (after all, keypresses going to untrusted apps
>> do keep the system awake)
>
> Again, this is up to the people creating the system in question. On
> some Android systems, there is a particular button you have to press
> to wake the system up after it has suspended itself.
note that here I am talking about thigns that will keep the system awake,
not wake it up after it suspends.
>>> There might well be other cases where networking packets -do- bring
>>> the system out of suspend, but I must leave this to someone who knows
>>> more about Android than do I.
>>
>> this would be the normal wake-on-lan type of functionality that
>> exists without Android.
>
> Although this wake-on-LAN functionality applies only to special
> wake-up packets, not to normal packets, right?
that's not my understanding. my understanding (which could be flawed) is
that wake-on-lan programs your IP into the NIC and if the NIC sees traffic
for you it will wake you up. I've never had a reason to use it, so I could
easily be mistaken.
David Lang
On Thu, Aug 05, 2010 at 02:13:00AM +0300, Anca Emanuel wrote:
> One suggestion: Get an Android Phone, test your ideas on it, then comment.
I actually have played with an Android phone. ;-)
Thanx, Paul
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 03:56:42PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>
>>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>>>
>>>>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>>>>> be entirely implemented in the form of binary that manually triggers
>>>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>>>>> event race. Imagine the following:
>>>>>>>
>>>>>>> 1) The policy timeout is about to expire. No applications are holding
>>>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>>>> suspending while the call is in progress
>>>>>>>
>>>>>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
>>>>>>> because the voip app is an otherwise untrusted application that you've
>>>>>>> just told the scheduler to ignore.
>>>>>>
>>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
>>>>>> to
>>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>>>
>>>>> Yes, I think that solves the problem. The only question then is whether
>>>>> it's preferable to use cgroups or suspend fully, which is pretty much up
>>>>> to the implementation. In other words, is there a reason we're still
>>>>> having this conversation? :) It'd be good to have some feedback from
>>>>> Google as to whether this satisfies their functional requirements.
>>>>
>>>> the proposal that I nade was not to use cgroups to freeze some processes and
>>>> not others, but to use cgroups to decide to ignore some processes when
>>>> deciding if the system is idle, stop everything or nothing. cgroups are just
>>>> a way of easily grouping processes (and their children) into different
>>>> groups.
>>>
>>> That does not avoid the dependency problem. A process may be waiting
>>> on a resource that a process you ignore owns. I you ignore the process
>>> that owns the resource and enter idle when it is ready to run (or
>>> waiting on a timer), you are still effectively blocking the other
>>> process.
>>
>> and if you don't have a wakelock the same thing will happen. If you
>> expect the process to take a while you can set a timeout to wake up
>> every 30 seconds or so and wait again, this would be enough to
>> prevent you from going to sleep (or am I misunderstanding how long
>> before you go into suspend without a wakelock set, see my other
>> e-mail for the full question)
>
> The difference between the Android scheme and your proposal is that the
> Android scheme freezes -all- the processes, not just a subset of them.
> Therefore, in the Android scheme, the case of one process attempting to
> acquire a resource held by a frozen process. In contrast, any scheme
> that attempts to freeze only a subset of the processes must somehow
> either avoid or properly handle the situation where a frozen process is
> holding a resource that a running process is trying to acquire.
My proposal would never freeze a subset of processes.
what my proposal:
only consider the activity of a subset of processes when deciding if we
should suspend or not. If the decision is to suspend, freeze everything.
you (and many other people) are confusing what I've proposed (use cgroups
to indicate what processes to care about and what ones to not care about
when deciding to suspend/go to idle) with the prior cgroup proposal (use
cgroups to freeze a subset of tasks while leaving others runnable)
David Lang
On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/4 <[email protected]>:
>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> On Wed, Aug 4, 2010 at 3:31 PM, ?<[email protected]> wrote:
>>>>
>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>
>>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>>>
>>>>>>> No! And that's precisely the issue. Android's existing behaviour could
>>>>>>> be entirely implemented in the form of binary that manually triggers
>>>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>>>> have indicated that the system shouldn't sleep, except for the wakeup
>>>>>>> event race. Imagine the following:
>>>>>>>
>>>>>>> 1) The policy timeout is about to expire. No applications are holding
>>>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
>>>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>>>> suspending while the call is in progress
>>>>>>>
>>>>>>> What stops the system going to sleep between (2) and (3)? cgroups
>>>>>>> don't,
>>>>>>> because the voip app is an otherwise untrusted application that you've
>>>>>>> just told the scheduler to ignore.
>>>>>>
>>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
>>>>>> to
>>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>>>
>>>>> Yes, I think that solves the problem. The only question then is whether
>>>>> it's preferable to use cgroups or suspend fully, which is pretty much up
>>>>> to the implementation. In other words, is there a reason we're still
>>>>> having this conversation? :) It'd be good to have some feedback from
>>>>> Google as to whether this satisfies their functional requirements.
>>>>
>>>> the proposal that I nade was not to use cgroups to freeze some processes
>>>> and
>>>> not others, but to use cgroups to decide to ignore some processes when
>>>> deciding if the system is idle, stop everything or nothing. cgroups are
>>>> just
>>>> a way of easily grouping processes (and their children) into different
>>>> groups.
>>>>
>>>
>>> That does not avoid the dependency problem. A process may be waiting
>>> on a resource that a process you ignore owns. I you ignore the process
>>> that owns the resource and enter idle when it is ready to run (or
>>> waiting on a timer), you are still effectively blocking the other
>>> process.
>>
>> and if you don't have a wakelock the same thing will happen. If you expect
>
> Not the same thing. If you don't hold a wakelock the entire system
> will suspend and when it wakes up it continues where it left off.
> Timeout still have time left before they expire.
in what I'm proposing, if the 'privilaged/trusted" processes are idle long
enough the entire system will suspend, and when it wakes up everything
will continue to process normally
>> the process to take a while you can set a timeout to wake up every 30
>> seconds or so and wait again, this would be enough to prevent you from going
>
> I don't think polling is an acceptable solution to this problem. You
> user space code know needs to know what "idle" timeout you have
> selected so it can choose a faster poll rate. When is it safe to stop
> polling?
I think the timeouts are of such an order of magnatude that the polling
can be infrequent enough to not be a significant amount of load, but be
faster than any timeout
>> to sleep (or am I misunderstanding how long before you go into suspend
>> without a wakelock set, see my other e-mail for the full question)
>>
>
> We suspend as soon as no wakelocks are held. There is no delay.
So, if I have a bookreader app that is not allowed to get the wakelock,
and nothing else is running, the system will suspend immediatly after I
click a button to go to the next page? it will not stay awake to give me a
chance to read the page at all?
how can any application run without wakelock privilages?
David Lang
On Thursday, August 05, 2010, [email protected] wrote:
> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>
> > Subject: Re: Attempted summary of suspend-blockers LKML thread
> >
> > On Wednesday, August 04, 2010, [email protected] wrote:
> >> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
> >>> In the suspend case, when you have frozen all applications, you can
> >>> sequentially disable all interrupts except for a few selected ("wakeup") ones
> >>> in a safe way. By disabling them, you ensure that the CPU will only be
> >>> "revived" by a limited set of events and that allows the system to stay
> >>> low-power for extended time intervals.
> >>
> >> the benifit of this will depend on what wakeups you are able to avoid by
> >> putting the hardware to sleep. Depending on the hardware, this may be not
> >> matter that much.
> >
> > That's correct, but evidently it does make a difference with the hardware
> > Android commonly runs on.
>
> Ok, but is there a way to put some of this to sleep without involving a
> full suspend?
Technically, maybe, but we have no generic infrastructure in the kernel for that.
There may be SoC-specific implementations, but nothing general enough.
> >> In addition, there are input devices like a touchscreen that could be
> >> disabled even short of a full suspend, as long as there is some way to get
> >> them reactivated.
> >
> > That's correct again, but it doesn't matter too much as far as the difference
> > between "deep idle" and suspend is concerned. These devices are generally not
> > the interrupt sources that are difficult to shut down safely in the "idle" case.
> >
> >>> To achieve the same result in the "idle" case, you'll need to have a mechanism
> >>> to disable interrupts (except for the "wakeup" ones) avoiding synchronization
> >>> problems (eg. situations in which task A, blocked on a "suspended" device
> >>> access, holds a mutex waited for by task B that needs to run so that we can
> >>> "suspend" another device). That, however, is a difficult problem.
> >>
> >> I would say that the difficulty of the problem depends on the hardware and
> >> how much userspace interaction is needed. If the kernel can disable the
> >> hardware in the driver (so that it can wake it up again when accessed by
> >> an application) it would seem that this isn't a problem.
> >
> > Well, I guess it's useful to consider the sequence of events in the "idle"
> > case.
> >
> > We first detect that a CPU is idle, so it can be put into a C-state (or
> > equivalent). It's easy to put that CPU into such a state, but suppose we
> > want to do more and put all devices into low-power states at that point.
> > We have to ensure that there are no devices in the middle of DMA and that
> > the other CPUs are idle (that's kind of easy, but still). Next, we have to
> > figure out the right ordering in which to put devices into low-power states
> > (that is not trivial, because the tasks that use those devices may depend on
> > each other in various ways). If we decide to shut down clock source
> > interrupts, we must ensure that the timekeeping will be correct after that and
> > so on. Moreover, things get ugly if there are shared interrupts.
> >
> > Suspend kind of works around these difficulties by taking the entire user
> > space out of the picture with one big sledgehammer called the freezer,
> > but these problems would have to be actually _solved_ in the "idle" case.
>
> I'm not opposed to doing a suspend if the system is idle enough, I'm just
> questioning if suspend is really that different, or if it can be viewed as
> yet another low power mode (one that's significantly more expensive to
> transition in and out of)
Suspend is really different. First, the way it is entered is different (ie. it
starts from the freezing of user space and sequentially powers down things
going from leaf devices towards the "core" of the system). Second, it shuts
down interrupt sources that cannot be easily shut down from idle (at least
in general). Finally, on some platforms (eg. ACPI) it requires extra hardware
black magic that cannot be triggered from the cpuidle context.
The deactivation of more interrupt sources appears to be the most significant
difference from the energy saving point of view, but it is achieved because of
the way suspend is entered. It may or may not be achieved in a different way,
but (1) no one has implemented anything close to a working alternative
solution yet and (2) it is not certain that's worth doing.
Thanks,
Rafael
On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
> >2010/8/4 <[email protected]>:
> >>On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>>On Wed, Aug 4, 2010 at 3:31 PM, ?<[email protected]> wrote:
> >>>>
> >>>>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>>
> >>>>>On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >>>>>>
> >>>>>>On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >>>>>>>
> >>>>>>>No! And that's precisely the issue. Android's existing behaviour could
> >>>>>>>be entirely implemented in the form of binary that manually triggers
> >>>>>>>suspend when (a) the screen is off and (b) no userspace applications
> >>>>>>>have indicated that the system shouldn't sleep, except for the wakeup
> >>>>>>>event race. Imagine the following:
> >>>>>>>
> >>>>>>>1) The policy timeout is about to expire. No applications are holding
> >>>>>>>wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>>>>>2) A network packet arrives indicating an incoming SIP call
> >>>>>>>3) The VOIP application takes a wakelock and prevents the phone from
> >>>>>>>suspending while the call is in progress
> >>>>>>>
> >>>>>>>What stops the system going to sleep between (2) and (3)? cgroups
> >>>>>>>don't,
> >>>>>>>because the voip app is an otherwise untrusted application that you've
> >>>>>>>just told the scheduler to ignore.
> >>>>>>
> >>>>>>I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
> >>>>>>to
> >>>>>>avoid the race (if pm_wakeup_event() is called at 2)).
> >>>>>
> >>>>>Yes, I think that solves the problem. The only question then is whether
> >>>>>it's preferable to use cgroups or suspend fully, which is pretty much up
> >>>>>to the implementation. In other words, is there a reason we're still
> >>>>>having this conversation? :) It'd be good to have some feedback from
> >>>>>Google as to whether this satisfies their functional requirements.
> >>>>
> >>>>the proposal that I nade was not to use cgroups to freeze some processes
> >>>>and
> >>>>not others, but to use cgroups to decide to ignore some processes when
> >>>>deciding if the system is idle, stop everything or nothing. cgroups are
> >>>>just
> >>>>a way of easily grouping processes (and their children) into different
> >>>>groups.
> >>>>
> >>>
> >>>That does not avoid the dependency problem. A process may be waiting
> >>>on a resource that a process you ignore owns. I you ignore the process
> >>>that owns the resource and enter idle when it is ready to run (or
> >>>waiting on a timer), you are still effectively blocking the other
> >>>process.
> >>
> >>and if you don't have a wakelock the same thing will happen. If you expect
> >
> >Not the same thing. If you don't hold a wakelock the entire system
> >will suspend and when it wakes up it continues where it left off.
> >Timeout still have time left before they expire.
>
> in what I'm proposing, if the 'privilaged/trusted" processes are
> idle long enough the entire system will suspend, and when it wakes
> up everything will continue to process normally
>
> >>the process to take a while you can set a timeout to wake up every 30
> >>seconds or so and wait again, this would be enough to prevent you from going
> >
> >I don't think polling is an acceptable solution to this problem. You
> >user space code know needs to know what "idle" timeout you have
> >selected so it can choose a faster poll rate. When is it safe to stop
> >polling?
>
> I think the timeouts are of such an order of magnatude that the
> polling can be infrequent enough to not be a significant amount of
> load, but be faster than any timeout
>
> >>to sleep (or am I misunderstanding how long before you go into suspend
> >>without a wakelock set, see my other e-mail for the full question)
> >>
> >
> >We suspend as soon as no wakelocks are held. There is no delay.
>
> So, if I have a bookreader app that is not allowed to get the
> wakelock, and nothing else is running, the system will suspend
> immediatly after I click a button to go to the next page? it will
> not stay awake to give me a chance to read the page at all?
>
> how can any application run without wakelock privilages?
Isn't a wakelock held as long as the display is lit, so that the
system would continue running as long as the page was visible?
Thanx, Paul
On Thursday, August 05, 2010, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
> > On Wed, Aug 04, 2010 at 03:56:42PM -0700, [email protected] wrote:
> >> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>> On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
> >>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
> >>>>
> >>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >>>>>>
> >>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >>>>>>>
> >>>>>>> No! And that's precisely the issue. Android's existing behaviour could
> >>>>>>> be entirely implemented in the form of binary that manually triggers
> >>>>>>> suspend when (a) the screen is off and (b) no userspace applications
> >>>>>>> have indicated that the system shouldn't sleep, except for the wakeup
> >>>>>>> event race. Imagine the following:
> >>>>>>>
> >>>>>>> 1) The policy timeout is about to expire. No applications are holding
> >>>>>>> wakelocks. The system will suspend providing nothing takes a wakelock.
> >>>>>>> 2) A network packet arrives indicating an incoming SIP call
> >>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
> >>>>>>> suspending while the call is in progress
> >>>>>>>
> >>>>>>> What stops the system going to sleep between (2) and (3)? cgroups don't,
> >>>>>>> because the voip app is an otherwise untrusted application that you've
> >>>>>>> just told the scheduler to ignore.
> >>>>>>
> >>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
> >>>>>> to
> >>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
> >>>>>
> >>>>> Yes, I think that solves the problem. The only question then is whether
> >>>>> it's preferable to use cgroups or suspend fully, which is pretty much up
> >>>>> to the implementation. In other words, is there a reason we're still
> >>>>> having this conversation? :) It'd be good to have some feedback from
> >>>>> Google as to whether this satisfies their functional requirements.
> >>>>
> >>>> the proposal that I nade was not to use cgroups to freeze some processes and
> >>>> not others, but to use cgroups to decide to ignore some processes when
> >>>> deciding if the system is idle, stop everything or nothing. cgroups are just
> >>>> a way of easily grouping processes (and their children) into different
> >>>> groups.
> >>>
> >>> That does not avoid the dependency problem. A process may be waiting
> >>> on a resource that a process you ignore owns. I you ignore the process
> >>> that owns the resource and enter idle when it is ready to run (or
> >>> waiting on a timer), you are still effectively blocking the other
> >>> process.
> >>
> >> and if you don't have a wakelock the same thing will happen. If you
> >> expect the process to take a while you can set a timeout to wake up
> >> every 30 seconds or so and wait again, this would be enough to
> >> prevent you from going to sleep (or am I misunderstanding how long
> >> before you go into suspend without a wakelock set, see my other
> >> e-mail for the full question)
> >
> > The difference between the Android scheme and your proposal is that the
> > Android scheme freezes -all- the processes, not just a subset of them.
> > Therefore, in the Android scheme, the case of one process attempting to
> > acquire a resource held by a frozen process. In contrast, any scheme
> > that attempts to freeze only a subset of the processes must somehow
> > either avoid or properly handle the situation where a frozen process is
> > holding a resource that a running process is trying to acquire.
>
> My proposal would never freeze a subset of processes.
>
> what my proposal:
>
> only consider the activity of a subset of processes when deciding if we
> should suspend or not. If the decision is to suspend, freeze everything.
That alone doesn't allow you to handle the race Matthew was referring to
(ie. wakeup event happening right after you've decided to suspend).
A mechanism of making a decision alone is not sufficient, you also need a
mechanism to avoid races between wakeup events and suspend process.
Thanks,
Rafael
2010/8/4 <[email protected]>:
> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>
>> 2010/8/4 ?<[email protected]>:
>>>
>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>
>>>> On Wed, Aug 4, 2010 at 3:31 PM, ?<[email protected]> wrote:
>>>>>
>>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>>
>>>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>>>>
>>>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>>>>
>>>>>>>> No! And that's precisely the issue. Android's existing behaviour
>>>>>>>> could
>>>>>>>> be entirely implemented in the form of binary that manually triggers
>>>>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>>>>> have indicated that the system shouldn't sleep, except for the
>>>>>>>> wakeup
>>>>>>>> event race. Imagine the following:
>>>>>>>>
>>>>>>>> 1) The policy timeout is about to expire. No applications are
>>>>>>>> holding
>>>>>>>> wakelocks. The system will suspend providing nothing takes a
>>>>>>>> wakelock.
>>>>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>>>>> suspending while the call is in progress
>>>>>>>>
>>>>>>>> What stops the system going to sleep between (2) and (3)? cgroups
>>>>>>>> don't,
>>>>>>>> because the voip app is an otherwise untrusted application that
>>>>>>>> you've
>>>>>>>> just told the scheduler to ignore.
>>>>>>>
>>>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count
>>>>>>> mechanism
>>>>>>> to
>>>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>>>>
>>>>>> Yes, I think that solves the problem. The only question then is
>>>>>> whether
>>>>>> it's preferable to use cgroups or suspend fully, which is pretty much
>>>>>> up
>>>>>> to the implementation. In other words, is there a reason we're still
>>>>>> having this conversation? :) It'd be good to have some feedback from
>>>>>> Google as to whether this satisfies their functional requirements.
>>>>>
>>>>> the proposal that I nade was not to use cgroups to freeze some
>>>>> processes
>>>>> and
>>>>> not others, but to use cgroups to decide to ignore some processes when
>>>>> deciding if the system is idle, stop everything or nothing. cgroups are
>>>>> just
>>>>> a way of easily grouping processes (and their children) into different
>>>>> groups.
>>>>>
>>>>
>>>> That does not avoid the dependency problem. A process may be waiting
>>>> on a resource that a process you ignore owns. I you ignore the process
>>>> that owns the resource and enter idle when it is ready to run (or
>>>> waiting on a timer), you are still effectively blocking the other
>>>> process.
>>>
>>> and if you don't have a wakelock the same thing will happen. If you
>>> expect
>>
>> Not the same thing. If you don't hold a wakelock the entire system
>> will suspend and when it wakes up it continues where it left off.
>> Timeout still have time left before they expire.
>
> in what I'm proposing, if the 'privilaged/trusted" processes are idle long
> enough the entire system will suspend, and when it wakes up everything will
> continue to process normally
>
If you are triggering a system suspend from idle (I assume all cpus
idle), you also have to consider when to resume. You cannot abort
suspend just because a cpu is not idle anymore, since suspend itself
will wake up threads.
>>> the process to take a while you can set a timeout to wake up every 30
>>> seconds or so and wait again, this would be enough to prevent you from
>>> going
>>
>> I don't think polling is an acceptable solution to this problem. You
>> user space code know needs to know what "idle" timeout you have
>> selected so it can choose a faster poll rate. When is it safe to stop
>> polling?
>
> I think the timeouts are of such an order of magnatude that the polling can
> be infrequent enough to not be a significant amount of load, but be faster
> than any timeout
>
How do you ever enter suspend in this system? Currently timers in the
kernel and trusted user space code causes a significant power draw and
you want insignificant timers to prevent suspend.
>>> to sleep (or am I misunderstanding how long before you go into suspend
>>> without a wakelock set, see my other e-mail for the full question)
>>>
>>
>> We suspend as soon as no wakelocks are held. There is no delay.
>
> So, if I have a bookreader app that is not allowed to get the wakelock, and
> nothing else is running, the system will suspend immediatly after I click a
> button to go to the next page? it will not stay awake to give me a chance to
> read the page at all?
>
> how can any application run without wakelock privilages?
A wakelock is active when the screen is on.
--
Arve Hj?nnev?g
On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
> On Thursday, August 05, 2010, [email protected] wrote:
>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>
>>> Subject: Re: Attempted summary of suspend-blockers LKML thread
>>>
>>> On Wednesday, August 04, 2010, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>>>> In the suspend case, when you have frozen all applications, you can
>>>>> sequentially disable all interrupts except for a few selected ("wakeup") ones
>>>>> in a safe way. By disabling them, you ensure that the CPU will only be
>>>>> "revived" by a limited set of events and that allows the system to stay
>>>>> low-power for extended time intervals.
>>>>
>>>> the benifit of this will depend on what wakeups you are able to avoid by
>>>> putting the hardware to sleep. Depending on the hardware, this may be not
>>>> matter that much.
>>>
>>> That's correct, but evidently it does make a difference with the hardware
>>> Android commonly runs on.
>>
>> Ok, but is there a way to put some of this to sleep without involving a
>> full suspend?
>
> Technically, maybe, but we have no generic infrastructure in the kernel for that.
> There may be SoC-specific implementations, but nothing general enough.
well, I know that we have specific cases of this (drive spin-down, cpu
speed, display backlight for a few examples), is it worth trying to define
a generic way to do this sort of thing? or should it be left as a
per-device thing (with per-device knobs to control it)
I thought I had seen discussion on how to define such a generic power
management interface, and I thought the results had been acceptable.
David Lang
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>>
>>> We suspend as soon as no wakelocks are held. There is no delay.
>>
>> So, if I have a bookreader app that is not allowed to get the
>> wakelock, and nothing else is running, the system will suspend
>> immediatly after I click a button to go to the next page? it will
>> not stay awake to give me a chance to read the page at all?
>>
>> how can any application run without wakelock privilages?
>
> Isn't a wakelock held as long as the display is lit, so that the
> system would continue running as long as the page was visible?
what holds this wakelock, and what sort of timeout does it have? (and why
could that same timeout be used in other ways instead)
how many apps really need to keep running after the screen blanks? there
are a few (audio output apps, including music player and Navigation
directions), but I don't have see a problem with them being marked as the
'trusted' apps to pay attention instead.
if the backlight being on holds the wakelock, it would seem that almost
every other use of the wakelock could (and probably should) be replaced by
something that tickles the display to stay on longer.
David Lang
On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
> On Thursday, August 05, 2010, [email protected] wrote:
>>
>> My proposal would never freeze a subset of processes.
>>
>> what my proposal:
>>
>> only consider the activity of a subset of processes when deciding if we
>> should suspend or not. If the decision is to suspend, freeze everything.
>
> That alone doesn't allow you to handle the race Matthew was referring to
> (ie. wakeup event happening right after you've decided to suspend).
>
> A mechanism of making a decision alone is not sufficient, you also need a
> mechanism to avoid races between wakeup events and suspend process.
>
I thought you just posted that there was a new feature that would be able
to abort the suspend and so that race was closed.
David Lang
On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> 2010/8/4 <[email protected]>:
>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>
>>> 2010/8/4 ?<[email protected]>:
>>>>
>>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>> On Wed, Aug 4, 2010 at 3:31 PM, ?<[email protected]> wrote:
>>>>>>
>>>>>> On Wed, 4 Aug 2010, Matthew Garrett wrote:
>>>>>>
>>>>>>> On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>>>>>>>>
>>>>>>>> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>>>>>>>>>
>>>>>>>>> No! And that's precisely the issue. Android's existing behaviour
>>>>>>>>> could
>>>>>>>>> be entirely implemented in the form of binary that manually triggers
>>>>>>>>> suspend when (a) the screen is off and (b) no userspace applications
>>>>>>>>> have indicated that the system shouldn't sleep, except for the
>>>>>>>>> wakeup
>>>>>>>>> event race. Imagine the following:
>>>>>>>>>
>>>>>>>>> 1) The policy timeout is about to expire. No applications are
>>>>>>>>> holding
>>>>>>>>> wakelocks. The system will suspend providing nothing takes a
>>>>>>>>> wakelock.
>>>>>>>>> 2) A network packet arrives indicating an incoming SIP call
>>>>>>>>> 3) The VOIP application takes a wakelock and prevents the phone from
>>>>>>>>> suspending while the call is in progress
>>>>>>>>>
>>>>>>>>> What stops the system going to sleep between (2) and (3)? cgroups
>>>>>>>>> don't,
>>>>>>>>> because the voip app is an otherwise untrusted application that
>>>>>>>>> you've
>>>>>>>>> just told the scheduler to ignore.
>>>>>>>>
>>>>>>>> I _think_ you can use the just-merged /sys/power/wakeup_count
>>>>>>>> mechanism
>>>>>>>> to
>>>>>>>> avoid the race (if pm_wakeup_event() is called at 2)).
>>>>>>>
>>>>>>> Yes, I think that solves the problem. The only question then is
>>>>>>> whether
>>>>>>> it's preferable to use cgroups or suspend fully, which is pretty much
>>>>>>> up
>>>>>>> to the implementation. In other words, is there a reason we're still
>>>>>>> having this conversation? :) It'd be good to have some feedback from
>>>>>>> Google as to whether this satisfies their functional requirements.
>>>>>>
>>>>>> the proposal that I nade was not to use cgroups to freeze some
>>>>>> processes
>>>>>> and
>>>>>> not others, but to use cgroups to decide to ignore some processes when
>>>>>> deciding if the system is idle, stop everything or nothing. cgroups are
>>>>>> just
>>>>>> a way of easily grouping processes (and their children) into different
>>>>>> groups.
>>>>>>
>>>>>
>>>>> That does not avoid the dependency problem. A process may be waiting
>>>>> on a resource that a process you ignore owns. I you ignore the process
>>>>> that owns the resource and enter idle when it is ready to run (or
>>>>> waiting on a timer), you are still effectively blocking the other
>>>>> process.
>>>>
>>>> and if you don't have a wakelock the same thing will happen. If you
>>>> expect
>>>
>>> Not the same thing. If you don't hold a wakelock the entire system
>>> will suspend and when it wakes up it continues where it left off.
>>> Timeout still have time left before they expire.
>>
>> in what I'm proposing, if the 'privilaged/trusted" processes are idle long
>> enough the entire system will suspend, and when it wakes up everything will
>> continue to process normally
>>
>
> If you are triggering a system suspend from idle (I assume all cpus
> idle), you also have to consider when to resume. You cannot abort
> suspend just because a cpu is not idle anymore, since suspend itself
> will wake up threads.
since the premise is that we only consider the activity of some processes
when we are deciding if the system is idle, it's very possible that not
all CPUs will be idle when we decide to suspend.
will suspend wake up the application threads? or will it create it's own
processes (and/or use processes that can be tagged ahead of time)?
>>>> the process to take a while you can set a timeout to wake up every 30
>>>> seconds or so and wait again, this would be enough to prevent you from
>>>> going
>>>
>>> I don't think polling is an acceptable solution to this problem. You
>>> user space code know needs to know what "idle" timeout you have
>>> selected so it can choose a faster poll rate. When is it safe to stop
>>> polling?
>>
>> I think the timeouts are of such an order of magnatude that the polling can
>> be infrequent enough to not be a significant amount of load, but be faster
>> than any timeout
>>
>
> How do you ever enter suspend in this system? Currently timers in the
> kernel and trusted user space code causes a significant power draw and
> you want insignificant timers to prevent suspend.
no, I want recent activity from a privilaged/trusted process to prevent
suspend. I'm saying that such a process can wake up infrequently enough
that the wakeups themselves are not a significant amount of processing if
it wants to keep the system awake so that other things can keep running.
you say below that the system will never suspend while the backlight is
on, well the process that monitors/controlls the backlight would be one of
these trusted processes.
>>>> to sleep (or am I misunderstanding how long before you go into suspend
>>>> without a wakelock set, see my other e-mail for the full question)
>>>>
>>>
>>> We suspend as soon as no wakelocks are held. There is no delay.
>>
>> So, if I have a bookreader app that is not allowed to get the wakelock, and
>> nothing else is running, the system will suspend immediatly after I click a
>> button to go to the next page? it will not stay awake to give me a chance to
>> read the page at all?
>>
>> how can any application run without wakelock privilages?
>
> A wakelock is active when the screen is on.
so what controls when the screen is on? what still needs to run (and keep
the system awake) if the screen is off?
David Lang
On Thursday, August 05, 2010, [email protected] wrote:
> On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
>
> > On Thursday, August 05, 2010, [email protected] wrote:
> >> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
> >>
> >>> Subject: Re: Attempted summary of suspend-blockers LKML thread
> >>>
> >>> On Wednesday, August 04, 2010, [email protected] wrote:
> >>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
> >>>>> In the suspend case, when you have frozen all applications, you can
> >>>>> sequentially disable all interrupts except for a few selected ("wakeup") ones
> >>>>> in a safe way. By disabling them, you ensure that the CPU will only be
> >>>>> "revived" by a limited set of events and that allows the system to stay
> >>>>> low-power for extended time intervals.
> >>>>
> >>>> the benifit of this will depend on what wakeups you are able to avoid by
> >>>> putting the hardware to sleep. Depending on the hardware, this may be not
> >>>> matter that much.
> >>>
> >>> That's correct, but evidently it does make a difference with the hardware
> >>> Android commonly runs on.
> >>
> >> Ok, but is there a way to put some of this to sleep without involving a
> >> full suspend?
> >
> > Technically, maybe, but we have no generic infrastructure in the kernel for that.
> > There may be SoC-specific implementations, but nothing general enough.
>
> well, I know that we have specific cases of this (drive spin-down, cpu
> speed, display backlight for a few examples), is it worth trying to define
> a generic way to do this sort of thing? or should it be left as a
> per-device thing (with per-device knobs to control it)
The ability to put specific devices into low-power states in certain
well-defined situations is clearly not sufficient. For one example, usually
you can easily put an Ethernet adapter into a low-power state when the network
cable is detached from it. It is not clear, however, what criteria should be
used for deciding to put that adapter into the low-power state when the cable
is attached to it (and open() has been called).
To mimic suspend you'll have to be able to put _all_ devices into low-power
states and shut down the interrupts that allow the monotonic clock to advance.
That's much more than simple runtime power management of selected devices.
> I thought I had seen discussion on how to define such a generic power
> management interface, and I thought the results had been acceptable.
If you have a pointer to that discussion, I'm interested. :-)
Thanks,
Rafael
On Thursday, August 05, 2010, [email protected] wrote:
> On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
>
> > On Thursday, August 05, 2010, [email protected] wrote:
> >>
> >> My proposal would never freeze a subset of processes.
> >>
> >> what my proposal:
> >>
> >> only consider the activity of a subset of processes when deciding if we
> >> should suspend or not. If the decision is to suspend, freeze everything.
> >
> > That alone doesn't allow you to handle the race Matthew was referring to
> > (ie. wakeup event happening right after you've decided to suspend).
> >
> > A mechanism of making a decision alone is not sufficient, you also need a
> > mechanism to avoid races between wakeup events and suspend process.
> >
>
> I thought you just posted that there was a new feature that would be able
> to abort the suspend and so that race was closed.
Yes, you can use that for this purpose, but then you'd need a user space
power manager who would decide whether or not to suspend. Then, however,
the problem boils down to setting up appropriate communication between the
power manager and the other applications in user space (ie. the kernel
doesn't need to be involved in that at all).
Thanks,
Rafael
On Wed, Aug 04, 2010 at 04:49:22PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
> >On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >>
> >>>
> >>>We suspend as soon as no wakelocks are held. There is no delay.
> >>
> >>So, if I have a bookreader app that is not allowed to get the
> >>wakelock, and nothing else is running, the system will suspend
> >>immediatly after I click a button to go to the next page? it will
> >>not stay awake to give me a chance to read the page at all?
> >>
> >>how can any application run without wakelock privilages?
> >
> >Isn't a wakelock held as long as the display is lit, so that the
> >system would continue running as long as the page was visible?
>
> what holds this wakelock, and what sort of timeout does it have?
> (and why could that same timeout be used in other ways instead)
I defer to the Android guys on what exactly holds the display's
wakelock. The timeout is the display-blank timeout.
> how many apps really need to keep running after the screen blanks?
> there are a few (audio output apps, including music player and
> Navigation directions), but I don't have see a problem with them
> being marked as the 'trusted' apps to pay attention instead.
Downloading is another.
The music player is an interesting example. It would be idle most
of the time, given that audio output doesn't consume very much CPU.
So you would not want to suspend the system just because there were
no runnable processes. In contrast, allowing the music player to
hold a wake lock lets the system know that it would not be appropriate
to suspend.
Or am I misunderstanding what you are proposing?
> if the backlight being on holds the wakelock, it would seem that
> almost every other use of the wakelock could (and probably should)
> be replaced by something that tickles the display to stay on longer.
The problem with this approach is that the display consumes quite a
bit of power, so you don't want to leave it on unnecessarily. So if
the system is doing something (for example, playing music) that does
not require the display, you really want the display to be off.
Thanx, Paul
On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >> > No! And that's precisely the issue. Android's existing behaviour could
> >> > be entirely implemented in the form of binary that manually triggers
> >> > suspend when (a) the screen is off and (b) no userspace applications
> >> > have indicated that the system shouldn't sleep, except for the wakeup
> >> > event race. Imagine the following:
> >> >
> >> > 1) The policy timeout is about to expire. No applications are holding
> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
> >> > 2) A network packet arrives indicating an incoming SIP call
> >> > 3) The VOIP application takes a wakelock and prevents the phone from
> >> > suspending while the call is in progress
> >> >
> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> >> > because the voip app is an otherwise untrusted application that you've
> >> > just told the scheduler to ignore.
> >>
> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> >> avoid the race (if pm_wakeup_event() is called at 2)).
> >
> > Yes, I think that solves the problem. The only question then is whether
>
> How? By passing a timeout to pm_wakeup_event when the network driver
> gets the packet or by passing 0. If you pass a timeout it is the same
> as using a wakelock with a timeout and should work (assuming the
> timeout you picked is long enough). If you don't pass a timeout it
> does not work, since the packet may not be visible to user-space yet.
Alternatively, pm_stay_awake() / pm_relax() can be used.
> > it's preferable to use cgroups or suspend fully, which is pretty much up
> > to the implementation. In other words, is there a reason we're still
>
> I have seen no proposed way to use cgroups that will work. If you
> leave some processes running while other processes are frozen you run
> into problems when a frozen process holds a resource that a running
> process needs.
>
>
> > having this conversation? :) It'd be good to have some feedback from
> > Google as to whether this satisfies their functional requirements.
> >
>
> That is "this"? The merged code? If so, no it does not satisfy our
> requirements. The in kernel api, while offering similar functionality
> to the wakelock interface, does not use any handles which makes it
> impossible to get reasonable stats (You don't know which pm_stay_awake
> request pm_relax is reverting).
Why is that a problem (out of curiosity)?
> The proposed in user-space interface
> of calling into every process that receives wakeup events before every
> suspend call
Well, you don't really need to do that.
> is also not compatible with existing apps.
Thanks,
Rafael
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 04:49:22PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>>
>>>>>
>>>>> We suspend as soon as no wakelocks are held. There is no delay.
>>>>
>>>> So, if I have a bookreader app that is not allowed to get the
>>>> wakelock, and nothing else is running, the system will suspend
>>>> immediatly after I click a button to go to the next page? it will
>>>> not stay awake to give me a chance to read the page at all?
>>>>
>>>> how can any application run without wakelock privilages?
>>>
>>> Isn't a wakelock held as long as the display is lit, so that the
>>> system would continue running as long as the page was visible?
>>
>> what holds this wakelock, and what sort of timeout does it have?
>> (and why could that same timeout be used in other ways instead)
>
> I defer to the Android guys on what exactly holds the display's
> wakelock. The timeout is the display-blank timeout.
>
>> how many apps really need to keep running after the screen blanks?
>> there are a few (audio output apps, including music player and
>> Navigation directions), but I don't have see a problem with them
>> being marked as the 'trusted' apps to pay attention instead.
>
> Downloading is another.
this is definantly an interesting case, do you want an active network
connection to keep the machine awake? if so do you want it for all network
connections, or only for some...
> The music player is an interesting example. It would be idle most
> of the time, given that audio output doesn't consume very much CPU.
> So you would not want to suspend the system just because there were
> no runnable processes. In contrast, allowing the music player to
> hold a wake lock lets the system know that it would not be appropriate
> to suspend.
>
> Or am I misunderstanding what you are proposing?
the system would need to be idle for 'long enough' (configurable) before
deciding to suspend, so as long as 'long enough' is longer than the music
player is idle this would not be a problem.
>> if the backlight being on holds the wakelock, it would seem that
>> almost every other use of the wakelock could (and probably should)
>> be replaced by something that tickles the display to stay on longer.
>
> The problem with this approach is that the display consumes quite a
> bit of power, so you don't want to leave it on unnecessarily. So if
> the system is doing something (for example, playing music) that does
> not require the display, you really want the display to be off.
what percentage (and types) of apps are really useful with the display
off. I think that there are relativly few apps that you really want to
keep running if the display is off.
David Lang
On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
> >On Wed, Aug 04, 2010 at 04:49:22PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>
> >>>On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
> >>>>On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >>>>
> >>>>>
> >>>>>We suspend as soon as no wakelocks are held. There is no delay.
> >>>>
> >>>>So, if I have a bookreader app that is not allowed to get the
> >>>>wakelock, and nothing else is running, the system will suspend
> >>>>immediatly after I click a button to go to the next page? it will
> >>>>not stay awake to give me a chance to read the page at all?
> >>>>
> >>>>how can any application run without wakelock privilages?
> >>>
> >>>Isn't a wakelock held as long as the display is lit, so that the
> >>>system would continue running as long as the page was visible?
> >>
> >>what holds this wakelock, and what sort of timeout does it have?
> >>(and why could that same timeout be used in other ways instead)
> >
> >I defer to the Android guys on what exactly holds the display's
> >wakelock. The timeout is the display-blank timeout.
> >
> >>how many apps really need to keep running after the screen blanks?
> >>there are a few (audio output apps, including music player and
> >>Navigation directions), but I don't have see a problem with them
> >>being marked as the 'trusted' apps to pay attention instead.
> >
> >Downloading is another.
>
> this is definantly an interesting case, do you want an active
> network connection to keep the machine awake? if so do you want it
> for all network connections, or only for some...
The Android approach is that everything is permitted to run when the
device is not suspended. So that would be all network connections.
> >The music player is an interesting example. It would be idle most
> >of the time, given that audio output doesn't consume very much CPU.
> >So you would not want to suspend the system just because there were
> >no runnable processes. In contrast, allowing the music player to
> >hold a wake lock lets the system know that it would not be appropriate
> >to suspend.
> >
> >Or am I misunderstanding what you are proposing?
>
> the system would need to be idle for 'long enough' (configurable)
> before deciding to suspend, so as long as 'long enough' is longer
> than the music player is idle this would not be a problem.
>From a user standpoint, having the music player tell the system when
it is OK to suspend (e.g., when the user has paused playback) seems
a lot nicer than having configurable timeouts that need tweaking.
> >>if the backlight being on holds the wakelock, it would seem that
> >>almost every other use of the wakelock could (and probably should)
> >>be replaced by something that tickles the display to stay on longer.
> >
> >The problem with this approach is that the display consumes quite a
> >bit of power, so you don't want to leave it on unnecessarily. So if
> >the system is doing something (for example, playing music) that does
> >not require the display, you really want the display to be off.
>
> what percentage (and types) of apps are really useful with the
> display off. I think that there are relativly few apps that you
> really want to keep running if the display is off.
The length of time those apps are running is the governing factor
for battery life, and not the number of such apps, right?
Thanx, Paul
2010/8/4 Rafael J. Wysocki <[email protected]>:
> On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
>> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
>> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>> >> > No! And that's precisely the issue. Android's existing behaviour could
>> >> > be entirely implemented in the form of binary that manually triggers
>> >> > suspend when (a) the screen is off and (b) no userspace applications
>> >> > have indicated that the system shouldn't sleep, except for the wakeup
>> >> > event race. Imagine the following:
>> >> >
>> >> > 1) The policy timeout is about to expire. No applications are holding
>> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
>> >> > 2) A network packet arrives indicating an incoming SIP call
>> >> > 3) The VOIP application takes a wakelock and prevents the phone from
>> >> > suspending while the call is in progress
>> >> >
>> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
>> >> > because the voip app is an otherwise untrusted application that you've
>> >> > just told the scheduler to ignore.
>> >>
>> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
>> >> avoid the race (if pm_wakeup_event() is called at 2)).
>> >
>> > Yes, I think that solves the problem. The only question then is whether
>>
>> How? By passing a timeout to pm_wakeup_event when the network driver
>> gets the packet or by passing 0. If you pass a timeout it is the same
>> as using a wakelock with a timeout and should work (assuming the
>> timeout you picked is long enough). If you don't pass a timeout it
>> does not work, since the packet may not be visible to user-space yet.
>
> Alternatively, pm_stay_awake() / pm_relax() can be used.
>
Which makes the driver and/or network stack changes identical to using
wakelocks, right?
>> > it's preferable to use cgroups or suspend fully, which is pretty much up
>> > to the implementation. In other words, is there a reason we're still
>>
>> I have seen no proposed way to use cgroups that will work. If you
>> leave some processes running while other processes are frozen you run
>> into problems when a frozen process holds a resource that a running
>> process needs.
>>
>>
>> > having this conversation? :) It'd be good to have some feedback from
>> > Google as to whether this satisfies their functional requirements.
>> >
>>
>> That is "this"? The merged code? If so, no it does not satisfy our
>> requirements. The in kernel api, while offering similar functionality
>> to the wakelock interface, does not use any handles which makes it
>> impossible to get reasonable stats (You don't know which pm_stay_awake
>> request pm_relax is reverting).
>
> Why is that a problem (out of curiosity)?
>
Not having stats or not knowing what pm_relax is undoing? We need
stats to be able to debug the system. If the system does not suspend
at all or is awake for too long, the wakelock stats tells us which
component is at fault. Since pm_stay_awake and pm_relax does not
operate on a handle, you cannot determine how long it prevented
suspend for.
>> The proposed in user-space interface
>> of calling into every process that receives wakeup events before every
>> suspend call
>
> Well, ?you don't really need to do that.
>
Only if the driver blocks suspend until user-space has read the event.
This means that for android to work we need to block suspend when
input events are not processed, but a system using your scheme needs a
pm_wakeup_event call when the input event is queued. How to you switch
between them? Do we add separate ioctls in the input device to enable
each scheme? If someone has a single threaded user space power manager
that also reads input event it will deadlock if you block suspend
until it reads the input events since you block when reading the wake
count.
>> is also not compatible with existing apps.
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
Arve Hj?nnev?g
On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 09:32:16AM -0700, Paul E. McKenney wrote:
>
> > If this doesn't work for the Android folks for whatever reason, another
> > approach would be to do the freeze in user code, which could track
> > whether any user-level resources (pthread mutexes, SysV semas, whatever)
> > where held, and do the freeze on a thread-by-thread basis within each
> > "victim" application as the threads reach safe points.
>
> The main problem I see with the cgroups solution is that it doesn't seem
> to do anything to handle avoiding loss of wakeup events.
cgroups alone don't but there is a solution which doesn't require routing
all event data through a single server -- use SIGIO.
Suppose we've got two cgroups of tasks -- those in the initial freezer
cgroup and those in a freezer cgroup meant for power-naive apps. Let's
call the second cgroup the naive cgroup.
One task -- let's call it the "waker" -- is in the initial cgroup is normaly
asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed
to be a non-power-naive task. It will be signaled via SIGIO by the
applications which want to be unfrozen when an event comes in.
When the power-naive app in the naive cgroup opens a file descriptor it's
going through the Android interpretter to make the syscall. The interpretter
can do fcntl() on the fd to cause SIGIO to be delivered to the waker task.
When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the
power-naive app. When the power-naive app wakes it will
poll/return-from-poll/read/return-from-read and thus retrieve the event.
Then it's just a matter of choosing when to freeze the naive cgroup. That
requires a userspace implementation of the suspend blockers API plus
opportunistic suspend but does not require any other kernel pieces. Then you
can use sigprocmask to prevent the freeze/wake-event race. You would
probably even merge the waker with the daemon which implements
opportunistic suspend.
Cheers,
-Matt Helsley
On Wed, Aug 4, 2010 at 6:58 PM, Matt Helsley <[email protected]> wrote:
> On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote:
>>
>> The main problem I see with the cgroups solution is that it doesn't seem
>> to do anything to handle avoiding loss of wakeup events.
>
> cgroups alone don't but there is a solution which doesn't require routing
> all event data through a single server -- use SIGIO.
>
> Suppose we've got two cgroups of tasks -- those in the initial freezer
> cgroup and those in a freezer cgroup meant for power-naive apps. Let's
> call the second cgroup the naive cgroup.
>
> One task -- let's call it the "waker" -- is in the initial cgroup is normaly
> asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed
> to be a non-power-naive task. It will be signaled via SIGIO by the
> applications which want to be unfrozen when an event comes in.
>
> When the power-naive app in the naive cgroup opens a file descriptor it's
> going through the Android interpretter to make the syscall. The interpretter
> can do fcntl() on the fd to cause SIGIO to be delivered to the waker task.
> When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the
> power-naive app. When the power-naive app wakes it will
> poll/return-from-poll/read/return-from-read and thus retrieve the event.
The Android execution model includes native code in addition to the
dalvik VM, and in the future could include other runtimes -- there are
many standard libraries that directly make posix file IO calls, and
apps can bundle native libraries which can also directly make
syscalls. It's not practical to instrument every piece of userspace
code that opens a fd somehow to make additional fcntl calls in various
places.
Brian
On Wed, Aug 04, 2010 at 03:08:33PM -0700, Arve Hj?nnev?g wrote:
> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
[ . . . ]
> > having this conversation? :) It'd be good to have some feedback from
> > Google as to whether this satisfies their functional requirements.
>
> That is "this"? The merged code? If so, no it does not satisfy our
> requirements. The in kernel api, while offering similar functionality
> to the wakelock interface, does not use any handles which makes it
> impossible to get reasonable stats (You don't know which pm_stay_awake
> request pm_relax is reverting). The proposed in user-space interface
> of calling into every process that receives wakeup events before every
> suspend call is also not compatible with existing apps.
I should have asked this earlier... What exactly are the apps'
compatibility constraints? Source-level APIs? Byte-code class-library
invocations? C/C++ dynamic linking? C/C++ static linking (in other
words, syscall)?
Thanx, Paul
2010/8/4 Paul E. McKenney <[email protected]>:
> On Wed, Aug 04, 2010 at 03:08:33PM -0700, Arve Hjønnevåg wrote:
>> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
>
> [ . . . ]
>
>> > having this conversation? :) It'd be good to have some feedback from
>> > Google as to whether this satisfies their functional requirements.
>>
>> That is "this"? The merged code? If so, no it does not satisfy our
>> requirements. The in kernel api, while offering similar functionality
>> to the wakelock interface, does not use any handles which makes it
>> impossible to get reasonable stats (You don't know which pm_stay_awake
>> request pm_relax is reverting). The proposed in user-space interface
>> of calling into every process that receives wakeup events before every
>> suspend call is also not compatible with existing apps.
>
> I should have asked this earlier... What exactly are the apps'
> compatibility constraints? Source-level APIs? Byte-code class-library
> invocations? C/C++ dynamic linking? C/C++ static linking (in other
> words, syscall)?
For Java/Dalvik apps, the wakelock API is pertty high level -- it
talks to a service via RPC (Binder) that actually interacts with the
kernel. Changing the basic kernel<->userspace interface (within
reason) is not unthinkable. For example, Arve's suspend_blocker patch
provides a device interface rather than the proc interface the older
wakelock patches use. We'd have to make some userspace changes to
support that but they're pretty low level and minor.
In the current model, only a few processes need to specifically
interact with the kernel (the power management service in the
system_server, possibly the media_server and the radio interface
glue). A model where every process needs to have a bunch of
instrumentation is not very desirable from our point of view. We
definitely do need reasonable statistics in order to enable debugging
and to enable reporting to endusers (through the Battery Usage UI)
what's keeping the device awake.
Brian
On Wed, Aug 04, 2010 at 07:02:55PM -0700, Brian Swetland wrote:
> On Wed, Aug 4, 2010 at 6:58 PM, Matt Helsley <[email protected]> wrote:
> > On Wed, Aug 04, 2010 at 05:35:09PM +0100, Matthew Garrett wrote:
> >>
> >> The main problem I see with the cgroups solution is that it doesn't seem
> >> to do anything to handle avoiding loss of wakeup events.
> >
> > cgroups alone don't but there is a solution which doesn't require routing
> > all event data through a single server -- use SIGIO.
> >
> > Suppose we've got two cgroups of tasks -- those in the initial freezer
> > cgroup and those in a freezer cgroup meant for power-naive apps. Let's
> > call the second cgroup the naive cgroup.
> >
> > One task -- let's call it the "waker" -- is in the initial cgroup is normaly
> > asleep waiting for SIGIO. Note it's not an "app" -- it's been trusted/blessed
> > to be a non-power-naive task. It will be signaled via SIGIO by the
> > applications which want to be unfrozen when an event comes in.
> >
> > When the power-naive app in the naive cgroup opens a file descriptor it's
> > going through the Android interpretter to make the syscall. The interpretter
> > can do fcntl() on the fd to cause SIGIO to be delivered to the waker task.
> > When the waker gets SIGIO it unfreezes the naive cgroup and thus wakes the
> > power-naive app. When the power-naive app wakes it will
> > poll/return-from-poll/read/return-from-read and thus retrieve the event.
>
> The Android execution model includes native code in addition to the
> dalvik VM, and in the future could include other runtimes -- there are
> many standard libraries that directly make posix file IO calls, and
> apps can bundle native libraries which can also directly make
> syscalls. It's not practical to instrument every piece of userspace
> code that opens a fd somehow to make additional fcntl calls in various
> places.
Perhaps using an LD_PRELOAD will work.
Cheers,
-Matt Helsley
On Wed, Aug 04, 2010 at 06:02:28PM -0700, Arve Hj?nnev?g wrote:
> 2010/8/4 Rafael J. Wysocki <[email protected]>:
> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >> >> > No! And that's precisely the issue. Android's existing behaviour could
> >> >> > be entirely implemented in the form of binary that manually triggers
> >> >> > suspend when (a) the screen is off and (b) no userspace applications
> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
> >> >> > event race. Imagine the following:
> >> >> >
> >> >> > 1) The policy timeout is about to expire. No applications are holding
> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
> >> >> > 2) A network packet arrives indicating an incoming SIP call
> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
> >> >> > suspending while the call is in progress
> >> >> >
> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> >> >> > because the voip app is an otherwise untrusted application that you've
> >> >> > just told the scheduler to ignore.
> >> >>
> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
> >> >
> >> > Yes, I think that solves the problem. The only question then is whether
> >>
> >> How? By passing a timeout to pm_wakeup_event when the network driver
> >> gets the packet or by passing 0. If you pass a timeout it is the same
> >> as using a wakelock with a timeout and should work (assuming the
> >> timeout you picked is long enough). If you don't pass a timeout it
> >> does not work, since the packet may not be visible to user-space yet.
> >
> > Alternatively, pm_stay_awake() / pm_relax() can be used.
>
> Which makes the driver and/or network stack changes identical to using
> wakelocks, right?
Arve, you say that like it is a bad thing. ;-)
Seriously, the hope is that Rafael's implementation is useful to other
projects in addition to Android. And, all else being equal, the more
people who need a given facility, the more likely that facility is to
make it to mainline, right?
And yes, I see you call out some additional things that Android needs,
but hopefully this gap can be closed one way or another.
Thanx, Paul
> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
> >> > to the implementation. In other words, is there a reason we're still
> >>
> >> I have seen no proposed way to use cgroups that will work. If you
> >> leave some processes running while other processes are frozen you run
> >> into problems when a frozen process holds a resource that a running
> >> process needs.
> >>
> >>
> >> > having this conversation? :) It'd be good to have some feedback from
> >> > Google as to whether this satisfies their functional requirements.
> >> >
> >>
> >> That is "this"? The merged code? If so, no it does not satisfy our
> >> requirements. The in kernel api, while offering similar functionality
> >> to the wakelock interface, does not use any handles which makes it
> >> impossible to get reasonable stats (You don't know which pm_stay_awake
> >> request pm_relax is reverting).
> >
> > Why is that a problem (out of curiosity)?
> >
>
> Not having stats or not knowing what pm_relax is undoing? We need
> stats to be able to debug the system. If the system does not suspend
> at all or is awake for too long, the wakelock stats tells us which
> component is at fault. Since pm_stay_awake and pm_relax does not
> operate on a handle, you cannot determine how long it prevented
> suspend for.
>
> >> The proposed in user-space interface
> >> of calling into every process that receives wakeup events before every
> >> suspend call
> >
> > Well, ?you don't really need to do that.
> >
>
> Only if the driver blocks suspend until user-space has read the event.
> This means that for android to work we need to block suspend when
> input events are not processed, but a system using your scheme needs a
> pm_wakeup_event call when the input event is queued. How to you switch
> between them? Do we add separate ioctls in the input device to enable
> each scheme? If someone has a single threaded user space power manager
> that also reads input event it will deadlock if you block suspend
> until it reads the input events since you block when reading the wake
> count.
>
> >> is also not compatible with existing apps.
> >
> > Thanks,
> > Rafael
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at ?http://www.tux.org/lkml/
> >
>
>
>
> --
> Arve Hj?nnev?g
On Wed, Aug 04, 2010 at 07:46:56PM -0700, Brian Swetland wrote:
> 2010/8/4 Paul E. McKenney <[email protected]>:
> > On Wed, Aug 04, 2010 at 03:08:33PM -0700, Arve Hj?nnev?g wrote:
> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> >
> > [ . . . ]
> >
> >> > having this conversation? :) It'd be good to have some feedback from
> >> > Google as to whether this satisfies their functional requirements.
> >>
> >> That is "this"? The merged code? If so, no it does not satisfy our
> >> requirements. The in kernel api, while offering similar functionality
> >> to the wakelock interface, does not use any handles which makes it
> >> impossible to get reasonable stats (You don't know which pm_stay_awake
> >> request pm_relax is reverting). The proposed in user-space interface
> >> of calling into every process that receives wakeup events before every
> >> suspend call is also not compatible with existing apps.
> >
> > I should have asked this earlier... ?What exactly are the apps'
> > compatibility constraints? ?Source-level APIs? ?Byte-code class-library
> > invocations? ?C/C++ dynamic linking? ?C/C++ static linking (in other
> > words, syscall)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. Changing the basic kernel<->userspace interface (within
> reason) is not unthinkable. For example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use. We'd have to make some userspace changes to
> support that but they're pretty low level and minor.
>
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue). A model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view. We
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
Thank you for the info!
Thanx, Paul
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 04:49:22PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>> On Wed, Aug 04, 2010 at 04:23:43PM -0700, [email protected] wrote:
>>>>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>>>>
>>>>>>>
>>>>>>> We suspend as soon as no wakelocks are held. There is no delay.
>>>>>>
>>>>>> So, if I have a bookreader app that is not allowed to get the
>>>>>> wakelock, and nothing else is running, the system will suspend
>>>>>> immediatly after I click a button to go to the next page? it will
>>>>>> not stay awake to give me a chance to read the page at all?
>>>>>>
>>>>>> how can any application run without wakelock privilages?
>>>>>
>>>>> Isn't a wakelock held as long as the display is lit, so that the
>>>>> system would continue running as long as the page was visible?
>>>>
>>>> what holds this wakelock, and what sort of timeout does it have?
>>>> (and why could that same timeout be used in other ways instead)
>>>
>>> I defer to the Android guys on what exactly holds the display's
>>> wakelock. The timeout is the display-blank timeout.
>>>
>>>> how many apps really need to keep running after the screen blanks?
>>>> there are a few (audio output apps, including music player and
>>>> Navigation directions), but I don't have see a problem with them
>>>> being marked as the 'trusted' apps to pay attention instead.
>>>
>>> Downloading is another.
>>
>> this is definantly an interesting case, do you want an active
>> network connection to keep the machine awake? if so do you want it
>> for all network connections, or only for some...
>
> The Android approach is that everything is permitted to run when the
> device is not suspended. So that would be all network connections.
I wasn't suggesting freezing some network connections while letting others
run, I was thinking in terms of 'if the system patcher daemon is
downloading, don't go to sleep, but if it's dancing cows (or mail client
to an IMAP server) go ahead and sleep, even if there is some data passing
over the connection.
>>> The music player is an interesting example. It would be idle most
>>> of the time, given that audio output doesn't consume very much CPU.
>>> So you would not want to suspend the system just because there were
>>> no runnable processes. In contrast, allowing the music player to
>>> hold a wake lock lets the system know that it would not be appropriate
>>> to suspend.
>>>
>>> Or am I misunderstanding what you are proposing?
>>
>> the system would need to be idle for 'long enough' (configurable)
>> before deciding to suspend, so as long as 'long enough' is longer
>> than the music player is idle this would not be a problem.
>
> From a user standpoint, having the music player tell the system when
> it is OK to suspend (e.g., when the user has paused playback) seems
> a lot nicer than having configurable timeouts that need tweaking.
every system that I have seen has a configurable "sleep if it's idle for
this long" knob. On the iphone (work issue, I didn't want it) that I am
currently using it can be configured from 1 min to 5 min.
this is the sort of timeout I am talking about.
with something in the multi-minute range for the 'do a full suspend' doing
a wakeup every few 10s of seconds is perfectly safe.
>>>> if the backlight being on holds the wakelock, it would seem that
>>>> almost every other use of the wakelock could (and probably should)
>>>> be replaced by something that tickles the display to stay on longer.
>>>
>>> The problem with this approach is that the display consumes quite a
>>> bit of power, so you don't want to leave it on unnecessarily. So if
>>> the system is doing something (for example, playing music) that does
>>> not require the display, you really want the display to be off.
>>
>> what percentage (and types) of apps are really useful with the
>> display off. I think that there are relativly few apps that you
>> really want to keep running if the display is off.
>
> The length of time those apps are running is the governing factor
> for battery life, and not the number of such apps, right?
correct, but the number of such apps indicates the scope of the problem.
>From another e-mail tonight it sounds like almost everything already talks
to a userspace daemon, so if "(the power management service in the
system_server, possibly the media_server and the radio interface
glue)" (plus possibly some kernel activity) are the only things looked at
when considering if it's safe to sleep or not, all of these can (or
already do) do 'something' every few seconds, making this problem sound
significantly smaller than it sounded like before.
Android could even keep it's user-space API between the system power
daemon and the rest of userspace the same if they want to.
over time, additional apps could be considered 'trusted' (or flagged that
way by the user) and not have to interact with the power daemon to keep
things alive.
as for intramentation, the key tool to use to see why a system isn't going
to sleep would be powertop, just like on other linux systems.
David Lang
On Wed, 4 Aug 2010 16:10:03 -0700
"Paul E. McKenney" <[email protected]> wrote:
> On Wed, Aug 04, 2010 at 03:56:42PM -0700, [email protected] wrote:
> > On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
> >
> > >On Wed, Aug 4, 2010 at 3:31 PM, <[email protected]> wrote:
> > >>On Wed, 4 Aug 2010, Matthew Garrett wrote:
> > >>
> > >>>On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> > >>>>
> > >>>>On Wednesday, August 04, 2010, Matthew Garrett wrote:
> > >>>>>
> > >>>>>No! And that's precisely the issue. Android's existing behaviour could
> > >>>>>be entirely implemented in the form of binary that manually triggers
> > >>>>>suspend when (a) the screen is off and (b) no userspace applications
> > >>>>>have indicated that the system shouldn't sleep, except for the wakeup
> > >>>>>event race. Imagine the following:
> > >>>>>
> > >>>>>1) The policy timeout is about to expire. No applications are holding
> > >>>>>wakelocks. The system will suspend providing nothing takes a wakelock.
> > >>>>>2) A network packet arrives indicating an incoming SIP call
> > >>>>>3) The VOIP application takes a wakelock and prevents the phone from
> > >>>>>suspending while the call is in progress
> > >>>>>
> > >>>>>What stops the system going to sleep between (2) and (3)? cgroups don't,
> > >>>>>because the voip app is an otherwise untrusted application that you've
> > >>>>>just told the scheduler to ignore.
> > >>>>
> > >>>>I _think_ you can use the just-merged /sys/power/wakeup_count mechanism
> > >>>>to
> > >>>>avoid the race (if pm_wakeup_event() is called at 2)).
> > >>>
> > >>>Yes, I think that solves the problem. The only question then is whether
> > >>>it's preferable to use cgroups or suspend fully, which is pretty much up
> > >>>to the implementation. In other words, is there a reason we're still
> > >>>having this conversation? :) It'd be good to have some feedback from
> > >>>Google as to whether this satisfies their functional requirements.
> > >>
> > >>the proposal that I nade was not to use cgroups to freeze some processes and
> > >>not others, but to use cgroups to decide to ignore some processes when
> > >>deciding if the system is idle, stop everything or nothing. cgroups are just
> > >>a way of easily grouping processes (and their children) into different
> > >>groups.
> > >
> > >That does not avoid the dependency problem. A process may be waiting
> > >on a resource that a process you ignore owns. I you ignore the process
> > >that owns the resource and enter idle when it is ready to run (or
> > >waiting on a timer), you are still effectively blocking the other
> > >process.
> >
> > and if you don't have a wakelock the same thing will happen. If you
> > expect the process to take a while you can set a timeout to wake up
> > every 30 seconds or so and wait again, this would be enough to
> > prevent you from going to sleep (or am I misunderstanding how long
> > before you go into suspend without a wakelock set, see my other
> > e-mail for the full question)
>
> The difference between the Android scheme and your proposal is that the
> Android scheme freezes -all- the processes, not just a subset of them.
> Therefore, in the Android scheme, the case of one process attempting to
> acquire a resource held by a frozen process. In contrast, any scheme
> that attempts to freeze only a subset of the processes must somehow
> either avoid or properly handle the situation where a frozen process is
> holding a resource that a running process is trying to acquire.
>
> Thanx, Paul
No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
is used. For idle decision a certain subset of tasks is ignored.
Where suspend is prevented by the trusted
process in android-world taking a wakelock, here it would just prevent
the system from going idle by arming timers.
This would be pretty equivalent to the suspend-blocker scheme and not
introduce new userspace api. But the downside is, as Arve pointed out,
that now one can not get full-idle-power-leverage while suspend
is blocked.
[1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and
following
Cheers,
Flo
On Thu, 5 Aug 2010 07:33:59 +0200
Florian Mickler <[email protected]> wrote:
> On Wed, 4 Aug 2010 16:10:03 -0700
> "Paul E. McKenney" <[email protected]> wrote:
>
> No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
> is used. For idle decision a certain subset of tasks is ignored.
>
> Where suspend is prevented by the trusted
> process in android-world taking a wakelock, here it would just prevent
> the system from going idle by arming timers.
>
> This would be pretty equivalent to the suspend-blocker scheme and not
> introduce new userspace api. But the downside is, as Arve pointed out,
> that now one can not get full-idle-power-leverage while suspend
> is blocked.
>
> [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and
> following
>
>
> Cheers,
> Flo
>
There are a few downsides that got mentioned already in reponse.. I got
a little lagged behind.
There are upsides to this approach like not
having a special purpose userspace api, conceptually integrating
suspend into the idle mechanism ..
Short summary of the cons that got mentioned:
- applications need to resort to polling to keep the system
out of idle (-> system will never be fully idle)
- the race between deciding to suspend and becoming active
again is not handled
- no special statistics available
- the timers of the ignored applications will behave unexpected
(as the monotonic clock is not stopped)... while applications
have already to cope with network-loss, other side effects of
suspend without monotonic clock stopped are to be expected...
Cheers,
Flo
On Thu, 5 Aug 2010, Florian Mickler wrote:
> On Thu, 5 Aug 2010 07:33:59 +0200
> Florian Mickler <[email protected]> wrote:
>
>> On Wed, 4 Aug 2010 16:10:03 -0700
>> "Paul E. McKenney" <[email protected]> wrote:
>
>>
>> No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
>> is used. For idle decision a certain subset of tasks is ignored.
>>
>> Where suspend is prevented by the trusted
>> process in android-world taking a wakelock, here it would just prevent
>> the system from going idle by arming timers.
>>
>> This would be pretty equivalent to the suspend-blocker scheme and not
>> introduce new userspace api. But the downside is, as Arve pointed out,
>> that now one can not get full-idle-power-leverage while suspend
>> is blocked.
>>
>> [1] http://permalink.gmane.org/gmane.linux.kernel/1018452 and
>> following
>>
>>
>> Cheers,
>> Flo
>>
>
> There are a few downsides that got mentioned already in reponse.. I got
> a little lagged behind.
>
> There are upsides to this approach like not
> having a special purpose userspace api, conceptually integrating
> suspend into the idle mechanism ..
first off, a good summary of that I've been saying, thanks.
> Short summary of the cons that got mentioned:
>
> - applications need to resort to polling to keep the system
> out of idle (-> system will never be fully idle)
true, although the power difference between a system that is
completelyidle (but with a wavelock held) and a system where one
application is polling every 10 seconds or so is _really_ low.
> - the race between deciding to suspend and becoming active
> again is not handled
this one I will admit to not fully understanding, it sounds like there are
opptions here, but I don't understand them or their trade-offs
> - no special statistics available
or no special statistics needed. Powertop is already avaible to analyse a
system and report what processes are keeping it awake. Why would this not
be enough?
> - the timers of the ignored applications will behave unexpected
> (as the monotonic clock is not stopped)... while applications
> have already to cope with network-loss, other side effects of
> suspend without monotonic clock stopped are to be expected...
I'm not sure this is true. there's nothing stopping the suspend (when it
finally does happen) from stopping the monotonic clock. The core of my
proposal is tweaking how we decide to suspend. Other than the possibility
that we decide to suspend between timers (and set an alarm to wake up when
a timer would go off) I'm not suggesting that the suspend itself change
once it's finally triggered.
David Lang
On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> Continuing to rush in where angels fear to tread...
here here :-)
> o "PM-driving 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,
> PM-driving applications seem to be those that have permission
> to exert some control over the system's sleep state.
>
> Note that an application might be power-oblivious on one Android
> device and PM-driving on another, depending on whether the user
> allows that application to acquire suspend blockers. The
> classification might even change over time. For example, a
> user might give an application PM-driving status initially,
> but change his or her mind after some experience with that
> application.
One thing that I think it's important to document here is theinformation
that Brian provided in response to your question about how many (or
actually how few) applications fall into this catefory
David Lang
Quote:
> I should have asked this earlier... What exactly are the apps'
> compatibility constraints? Source-level APIs? Byte-code class-library
> invocations? C/C++ dynamic linking? C/C++ static linking (in other
> words, syscall)?
For Java/Dalvik apps, the wakelock API is pertty high level -- it
talks to a service via RPC (Binder) that actually interacts with the
kernel. Changing the basic kernel<->userspace interface (within
reason) is not unthinkable. For example, Arve's suspend_blocker patch
provides a device interface rather than the proc interface the older
wakelock patches use. We'd have to make some userspace changes to
support that but they're pretty low level and minor.
In the current model, only a few processes need to specifically
interact with the kernel (the power management service in the
system_server, possibly the media_server and the radio interface
glue). A model where every process needs to have a bunch of
instrumentation is not very desirable from our point of view. We
definitely do need reasonable statistics in order to enable debugging
and to enable reporting to endusers (through the Battery Usage UI)
what's keeping the device awake.
Brian
On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
> On Thursday, August 05, 2010, [email protected] wrote:
>> On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
>>
>>> On Thursday, August 05, 2010, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>>>
>>>>> Subject: Re: Attempted summary of suspend-blockers LKML thread
>>>>>
>>>>> On Wednesday, August 04, 2010, [email protected] wrote:
>>>>>> On Wed, 4 Aug 2010, Rafael J. Wysocki wrote:
>>>>>>> In the suspend case, when you have frozen all applications, you can
>>>>>>> sequentially disable all interrupts except for a few selected ("wakeup") ones
>>>>>>> in a safe way. By disabling them, you ensure that the CPU will only be
>>>>>>> "revived" by a limited set of events and that allows the system to stay
>>>>>>> low-power for extended time intervals.
>>>>>>
>>>>>> the benifit of this will depend on what wakeups you are able to avoid by
>>>>>> putting the hardware to sleep. Depending on the hardware, this may be not
>>>>>> matter that much.
>>>>>
>>>>> That's correct, but evidently it does make a difference with the hardware
>>>>> Android commonly runs on.
>>>>
>>>> Ok, but is there a way to put some of this to sleep without involving a
>>>> full suspend?
>>>
>>> Technically, maybe, but we have no generic infrastructure in the kernel for that.
>>> There may be SoC-specific implementations, but nothing general enough.
>>
>> well, I know that we have specific cases of this (drive spin-down, cpu
>> speed, display backlight for a few examples), is it worth trying to define
>> a generic way to do this sort of thing? or should it be left as a
>> per-device thing (with per-device knobs to control it)
>
> The ability to put specific devices into low-power states in certain
> well-defined situations is clearly not sufficient. For one example, usually
> you can easily put an Ethernet adapter into a low-power state when the network
> cable is detached from it. It is not clear, however, what criteria should be
> used for deciding to put that adapter into the low-power state when the cable
> is attached to it (and open() has been called).
>
> To mimic suspend you'll have to be able to put _all_ devices into low-power
> states and shut down the interrupts that allow the monotonic clock to advance.
> That's much more than simple runtime power management of selected devices.
true for the generic case, my thought was that for specially built
hardware it may be possible to select hardware that lets you get very
close.
>> I thought I had seen discussion on how to define such a generic power
>> management interface, and I thought the results had been acceptable.
>
> If you have a pointer to that discussion, I'm interested. :-)
sorry, it was several months ago.
David Lang
On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
> On Thursday, August 05, 2010, [email protected] wrote:
>> On Thu, 5 Aug 2010, Rafael J. Wysocki wrote:
>>
>>> On Thursday, August 05, 2010, [email protected] wrote:
>>>>
>>>> My proposal would never freeze a subset of processes.
>>>>
>>>> what my proposal:
>>>>
>>>> only consider the activity of a subset of processes when deciding if we
>>>> should suspend or not. If the decision is to suspend, freeze everything.
>>>
>>> That alone doesn't allow you to handle the race Matthew was referring to
>>> (ie. wakeup event happening right after you've decided to suspend).
>>>
>>> A mechanism of making a decision alone is not sufficient, you also need a
>>> mechanism to avoid races between wakeup events and suspend process.
>>>
>>
>> I thought you just posted that there was a new feature that would be able
>> to abort the suspend and so that race was closed.
>
> Yes, you can use that for this purpose, but then you'd need a user space
> power manager who would decide whether or not to suspend. Then, however,
> the problem boils down to setting up appropriate communication between the
> power manager and the other applications in user space (ie. the kernel
> doesn't need to be involved in that at all).
This race sounds like it's generic across all platforms and not an Android
specific problem. Android is just more sensitive to it as they do a
suspend more frequently.
one thought on this, as a generic solution to the problem would it be
possible for the suspend controller (whatever it is) to do the
following
1. decide to suspend
2. setup monitors for the wake events
3. double check if it still wants to suspend
this way you don't pay the overhead of the wake monitors while you are
running normally, but if one hits while you are suspending you wake up
again as quickly as you can (which could involve aborting the suspend and
backing out, or going fully into suspend and waking up immediatly,
depending on which is better/easier at the time you get the wakeup)
David Lang
On Wed, Aug 04, 2010 at 03:20:04PM -0700, [email protected] wrote:
> on the other hand, making an application avoid consuming inappropriate
> background resources helps everywhere. an explicit "don't let the machine
> sleep" only works if you are trusted by a system that implements this
> flag.
>
> yes, it is painful to make the change, but the end result is better (and
> there are more tools out there to figure things out)
Nobody's denying that it's better, but people are saying they want to
design a platform that's capable of handling the software we have rather
than the software we'd like to have.
> but if you have an application in the mid-level trust situation, go ahead
> and have it talk to a 'keepalive' daemon that is in the 'trusted' set and
> let the rest of the app run untrusted. As I noted elsewhere, the
> keepalive daemon would need very little in the way of resources and can
> implement much more complex policies than anyone is going to be willing
> to put in the kernel.
That doesn't work. You'll race with wakeup events.
> similar to the current implementation, the arrival of a packet could be
> counted as activity that keeps the system awake for a bit (your timeout)
How? You're either polling in order to know whether there's network
activity, or you're having every network packet wake up the policy
daemon, or you've got something that looks like the kernel side of
wakelocks.
>> Cell networks typically have no background traffic, for obvious reasons.
>
> but don't most new smartphones also connect up to wifi networks? those
> are FAR from quiet.
Wifi radio typically dwarfs your other power consumption anyway. The
typical situation is one where you're not attached to a wifi network.
> I'm not suggesting running all events through some central server (unless
> you count the kernel as that server), I'm saying that the decision that
> the system is idle and therefor can be stopped should be able to take
> this infomation into account, and if there's a race here, it should be a
> race that exists everywhere else, so there should be a general solution,
> not something specific to one use-case. (and definantly not something
> that requires all software to be modified and trusted to implement)
You're right. It's a race that exists everywhere else, and it's inherent
unless you have some handshaking between userspace and the kernel when
entering suspend. Which is what wakelocks provide. Nobody has proposed a
solution that works without modifying existing code.
--
Matthew Garrett | [email protected]
On Thu, Aug 5, 2010 at 6:18 AM, <[email protected]> wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
>> Continuing to rush in where angels fear to tread...
>
> here here :-)
>
>> o "PM-driving 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,
>> PM-driving applications seem to be those that have permission
>> to exert some control over the system's sleep state.
>>
>> Note that an application might be power-oblivious on one Android
>> device and PM-driving on another, depending on whether the user
>> allows that application to acquire suspend blockers. The
>> classification might even change over time. For example, a
>> user might give an application PM-driving status initially,
>> but change his or her mind after some experience with that
>> application.
>
> One thing that I think it's important to document here is theinformation
> that Brian provided in response to your question about how many (or actually
> how few) applications fall into this catefory
I think I need to clarify here. When I say "app" in the context of
Android, I mean "an application running under the Android app model --
sandboxed under a per-app or app-group uid", not "a process". The
vast majority of processes on an Android device are "apps" in this
sense, but some (usually low level services or daemons) are not. Also
I use "wakelock" as a place holder for "suspend blocker" or whatever
exact API we're trying to hash out here, because it's shorter and I'm
lazy.
Any app may obtain a wakelock through the standard Android APIs,
provided it has permission to do so. In the current implementation,
apps obtain wakelocks via making a binder RPC call to the power
manager service which tracks high level wakelocks (for apps!) and
backs them by a single kernel wakelock. Access control is at the RPC
level. This implementation could be changed to have the app API
simply open /dev/suspendblock or whatnot, with access control enforced
by unix permissions (the framework would arrange for apps with the
android "can block sleep" permission to be in a unix group that has
access to the device).
For native services (native daemons that run "underneath" the android
app framework -- for example the media service, the radio interface,
etc), the kernel interface is used directly (ok, usually via a very
thin C convenience wrapper).
Brian
> Quote:
>
>> I should have asked this earlier... What exactly are the apps'
>> compatibility constraints? Source-level APIs? Byte-code class-library
>> invocations? C/C++ dynamic linking? C/C++ static linking (in other
>> words, syscall)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. Changing the basic kernel<->userspace interface (within
> reason) is not unthinkable. For example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use. We'd have to make some userspace changes to
> support that but they're pretty low level and minor.
>
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue). A model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view. We
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
>
> Brian
>
>
On Wed, Aug 04, 2010 at 06:02:28PM -0700, Arve Hj?nnev?g wrote:
> Which makes the driver and/or network stack changes identical to using
> wakelocks, right?
I think we're resigned to the fact that we need to indicate wakeup
events in a manner that's pretty equivalent to wakelocks. The only real
issue is what the API looks like. Anyone who's still talking about
cgroups seems to be trying to solve a different problem.
--
Matthew Garrett | [email protected]
On Wed, Aug 04, 2010 at 04:19:20PM -0700, [email protected] wrote:
> only consider the activity of a subset of processes when deciding if we
> should suspend or not. If the decision is to suspend, freeze everything.
>
> you (and many other people) are confusing what I've proposed (use cgroups
> to indicate what processes to care about and what ones to not care about
> when deciding to suspend/go to idle) with the prior cgroup proposal (use
> cgroups to freeze a subset of tasks while leaving others runnable)
The decision on whether or not to go to sleep isn't the difficult bit of
this problem space.
--
Matthew Garrett | [email protected]
On Thu, 5 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 04:19:20PM -0700, [email protected] wrote:
>
>> only consider the activity of a subset of processes when deciding if we
>> should suspend or not. If the decision is to suspend, freeze everything.
>>
>> you (and many other people) are confusing what I've proposed (use cgroups
>> to indicate what processes to care about and what ones to not care about
>> when deciding to suspend/go to idle) with the prior cgroup proposal (use
>> cgroups to freeze a subset of tasks while leaving others runnable)
>
> The decision on whether or not to go to sleep isn't the difficult bit of
> this problem space.
but isn't that all that wakelocks do? affect the decision on whether or
not to go to sleep.
David Lang
On Thu, Aug 05, 2010 at 07:07:06AM -0700, [email protected] wrote:
> On Thu, 5 Aug 2010, Matthew Garrett wrote:
>> The decision on whether or not to go to sleep isn't the difficult bit of
>> this problem space.
>
> but isn't that all that wakelocks do? affect the decision on whether or
> not to go to sleep.
You could think of them that way, but it's not the useful aspect of them
- that much could be implemented entirely in userspace. Wakelocks
provide a mechanism for userspace to ensure that it's handled all
received events before a system suspend takes place.
--
Matthew Garrett | [email protected]
On Thu, Aug 5, 2010 at 7:16 AM, Matthew Garrett <[email protected]> wrote:
> On Thu, Aug 05, 2010 at 07:07:06AM -0700, [email protected] wrote:
>> On Thu, 5 Aug 2010, Matthew Garrett wrote:
>>> The decision on whether or not to go to sleep isn't the difficult bit of
>>> this problem space.
>>
>> but isn't that all that wakelocks do? affect the decision on whether or
>> not to go to sleep.
>
> You could think of them that way, but it's not the useful aspect of them
> - that much could be implemented entirely in userspace. Wakelocks
> provide a mechanism for userspace to ensure that it's handled all
> received events before a system suspend takes place.
For userspace or the kernel -- some events may not require userspace
intervention, but do require the kernel to stay awake long enough to
finish chewing on them. Say perhaps a wifi irq comes in, the wifi
driver/stack needs to process some beacon packets or whatnot.
Brian
On Thu, 5 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 06:02:28PM -0700, Arve Hj?nnev?g wrote:
>
>> Which makes the driver and/or network stack changes identical to using
>> wakelocks, right?
>
> I think we're resigned to the fact that we need to indicate wakeup
> events in a manner that's pretty equivalent to wakelocks. The only real
> issue is what the API looks like. Anyone who's still talking about
> cgroups seems to be trying to solve a different problem.
Ok, it is now sounding to me like there are two different (but somewhat
related) purposes that wakelocks are being used for
1. deciding if the system should go to sleep now or not (what most of the
discussion has been about)
2. narrowing the race between going to sleep and wakeup events.
I'm not sure it's possible to completely eliminate the race, even with
wakelocks there is some time between the time you last check if the
wakelock is set and when the hardware finishes responding to your commands
to go to sleep (Unless you can set a level-based interrupt that will wake
you up as soon as you finish going to sleep)
David Lang
On Thu, Aug 5, 2010 at 7:22 AM, <[email protected]> wrote:
>
> Ok, it is now sounding to me like there are two different (but somewhat
> related) purposes that wakelocks are being used for
>
> 1. deciding if the system should go to sleep now or not (what most of the
> discussion has been about)
>
> 2. narrowing the race between going to sleep and wakeup events.
>
> I'm not sure it's possible to completely eliminate the race, even with
> wakelocks there is some time between the time you last check if the wakelock
> is set and when the hardware finishes responding to your commands to go to
> sleep (Unless you can set a level-based interrupt that will wake you up as
> soon as you finish going to sleep)
The transition into sleep is race-free in the wakelock model -- either
the wakeup event happens during the kernel suspend (and grabs a
wakelock), in which case suspend is aborted (and not attempted again
until there are once again no more wakelocks held), or the system
fully suspends to its lowest power mode until a wakeup event brings it
back out again. Entry to lowest power mode must abort if a wakeup
event/interrupt occurs while it's in process -- exactly how the
handoff happens here is hardware dependent but in practice this is
doable on just about any modern system.
Brian
On Thu, Aug 05, 2010 at 07:22:53AM -0700, [email protected] wrote:
> I'm not sure it's possible to completely eliminate the race, even with
> wakelocks there is some time between the time you last check if the
> wakelock is set and when the hardware finishes responding to your
> commands to go to sleep (Unless you can set a level-based interrupt that
> will wake you up as soon as you finish going to sleep)
It's typically the case that you can - we've even seen that on x86 with
ACPI GPEs.
--
Matthew Garrett | [email protected]
On Thu, 5 Aug 2010, Matthew Garrett wrote:
> On Wed, Aug 04, 2010 at 03:20:04PM -0700, [email protected] wrote:
>
>> similar to the current implementation, the arrival of a packet could be
>> counted as activity that keeps the system awake for a bit (your timeout)
>
> How? You're either polling in order to know whether there's network
> activity, or you're having every network packet wake up the policy
> daemon, or you've got something that looks like the kernel side of
> wakelocks.
infrequent polling (on the order of seconds or 10s of seconds) is not a
very significant impact on your power
>>> Cell networks typically have no background traffic, for obvious reasons.
>>
>> but don't most new smartphones also connect up to wifi networks? those
>> are FAR from quiet.
>
> Wifi radio typically dwarfs your other power consumption anyway. The
> typical situation is one where you're not attached to a wifi network.
on some devices (my kindle for example) the cell network dwarfs my other
power consumption today.
>> I'm not suggesting running all events through some central server (unless
>> you count the kernel as that server), I'm saying that the decision that
>> the system is idle and therefor can be stopped should be able to take
>> this infomation into account, and if there's a race here, it should be a
>> race that exists everywhere else, so there should be a general solution,
>> not something specific to one use-case. (and definantly not something
>> that requires all software to be modified and trusted to implement)
>
> You're right. It's a race that exists everywhere else, and it's inherent
> unless you have some handshaking between userspace and the kernel when
> entering suspend. Which is what wakelocks provide. Nobody has proposed a
> solution that works without modifying existing code.
I think the issue is confusion between the different purposes of the
wakelock.
as you say, I don't think anyone is opposed to the kernel being modified
to eliminate this race. The disagreement is far more about the interface
to userspace and userspace use of wakelocks.
the kernel implementation of this doesn't have to set a single flag, and
it doesn't have to notify userspace directly. The kernel already produces
many stats today and it may be appropriate for the kernel to produce some
more.
for example, if you want to abort the suspend because there is network
activity, you can check the packet count of your network interface, decide
to go to sleep, setup the network interface to raise a 'wake me up'
interrupt (because you have decided in a userspace policy that you want
this), and then check to see if the packet count has changed. If it has,
abort the suspend, if not continue the suspend and once you are suspended
if the 'wake me up' interrupt is set you will wake back up.
there are probably cleaner/better ways of doing this than the simple logic
that I'm listing, but why wouldn't the simple logic provide the correct
result?
David Lang
On Thu, Aug 05, 2010 at 06:18:42AM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
> >Continuing to rush in where angels fear to tread...
>
> here here :-)
>
> >o "PM-driving 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,
> > PM-driving applications seem to be those that have permission
> > to exert some control over the system's sleep state.
> >
> > Note that an application might be power-oblivious on one Android
> > device and PM-driving on another, depending on whether the user
> > allows that application to acquire suspend blockers. The
> > classification might even change over time. For example, a
> > user might give an application PM-driving status initially,
> > but change his or her mind after some experience with that
> > application.
>
> One thing that I think it's important to document here is
> theinformation that Brian provided in response to your question
> about how many (or actually how few) applications fall into this
> catefory
Agreed!!! I have added this, and it will appear in the next version.
Thanx, Paul
> David Lang
>
> Quote:
>
> >I should have asked this earlier... What exactly are the apps'
> >compatibility constraints? Source-level APIs? Byte-code class-library
> >invocations? C/C++ dynamic linking? C/C++ static linking (in other
> >words, syscall)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. Changing the basic kernel<->userspace interface (within
> reason) is not unthinkable. For example, Arve's suspend_blocker patch
> provides a device interface rather than the proc interface the older
> wakelock patches use. We'd have to make some userspace changes to
> support that but they're pretty low level and minor.
>
> In the current model, only a few processes need to specifically
> interact with the kernel (the power management service in the
> system_server, possibly the media_server and the radio interface
> glue). A model where every process needs to have a bunch of
> instrumentation is not very desirable from our point of view. We
> definitely do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery Usage UI)
> what's keeping the device awake.
>
> Brian
>
On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
[ . . . ]
> >>>The music player is an interesting example. It would be idle most
> >>>of the time, given that audio output doesn't consume very much CPU.
> >>>So you would not want to suspend the system just because there were
> >>>no runnable processes. In contrast, allowing the music player to
> >>>hold a wake lock lets the system know that it would not be appropriate
> >>>to suspend.
> >>>
> >>>Or am I misunderstanding what you are proposing?
> >>
> >>the system would need to be idle for 'long enough' (configurable)
> >>before deciding to suspend, so as long as 'long enough' is longer
> >>than the music player is idle this would not be a problem.
> >
> >From a user standpoint, having the music player tell the system when
> >it is OK to suspend (e.g., when the user has paused playback) seems
> >a lot nicer than having configurable timeouts that need tweaking.
>
> every system that I have seen has a configurable "sleep if it's idle
> for this long" knob. On the iphone (work issue, I didn't want it)
> that I am currently using it can be configured from 1 min to 5 min.
>
> this is the sort of timeout I am talking about.
>
> with something in the multi-minute range for the 'do a full suspend'
> doing a wakeup every few 10s of seconds is perfectly safe.
Ah, I was assuming -much- shorter "do full suspend" timeouts.
My (possibly incorrect) assumption is based on the complaint that led
to my implementing RCU_FAST_NO_HZ. A (non-Android) embedded person was
quite annoyed (to put it mildly) at the earlier version of RCU because
it prevented the system from entering the power-saving dyntick-idle mode,
not for minutes, or even for seconds, but for a handful of -milliseconds-.
This was my first hint that "energy efficiency" means something completely
different in embedded systems than it does in the servers that I am
used to.
But I must defer to the Android guys on this -- who knows, perhaps
multi-minute delays to enter full-suspend mode are OK for them.
> >>>>if the backlight being on holds the wakelock, it would seem that
> >>>>almost every other use of the wakelock could (and probably should)
> >>>>be replaced by something that tickles the display to stay on longer.
> >>>
> >>>The problem with this approach is that the display consumes quite a
> >>>bit of power, so you don't want to leave it on unnecessarily. So if
> >>>the system is doing something (for example, playing music) that does
> >>>not require the display, you really want the display to be off.
> >>
> >>what percentage (and types) of apps are really useful with the
> >>display off. I think that there are relativly few apps that you
> >>really want to keep running if the display is off.
> >
> >The length of time those apps are running is the governing factor
> >for battery life, and not the number of such apps, right?
>
> correct, but the number of such apps indicates the scope of the problem.
The number of such apps certainly indicates the amount of effort required
to modify them, if required. Is that what you are getting at?
> >From another e-mail tonight it sounds like almost everything
> >already talks
>
> to a userspace daemon, so if "(the power management service in the
> system_server, possibly the media_server and the radio interface
> glue)" (plus possibly some kernel activity) are the only things
> looked at when considering if it's safe to sleep or not, all of
> these can (or already do) do 'something' every few seconds, making
> this problem sound significantly smaller than it sounded like
> before.
>
> Android could even keep it's user-space API between the system power
> daemon and the rest of userspace the same if they want to.
>
> over time, additional apps could be considered 'trusted' (or flagged
> that way by the user) and not have to interact with the power daemon
> to keep things alive.
Hmmm... Isn't it the "trusted" (AKA PM-driving) apps that interact with
the power daemon via suspend blockers, rather than the other way around?
> as for intramentation, the key tool to use to see why a system isn't
> going to sleep would be powertop, just like on other linux systems.
Powertop is indeed an extremely valuable tool, but I am not certain
that it really provides the information that the Android guys need.
If I understand Arve's and Brian's posts, here is the scenario that they
are trying to detect:
o Some PM-driving application has a bug in which it fails to
release a wakelock, thus blocking suspend indefinitely.
o This PM-driving application, otherwise being a good citizen,
blocks.
o There are numerous power-oblivious apps running, consuming
significant CPU.
What the Android developers need to know is that the trusted application
is wrongly holding a wakelock. Won't powertop instead tell them about
all the power-oblivious apps?
Thanx, Paul
On Thu, Aug 5, 2010 at 7:34 AM, <[email protected]> wrote:
>
> for example, if you want to abort the suspend because there is network
> activity, you can check the packet count of your network interface, decide
> to go to sleep, setup the network interface to raise a 'wake me up'
> interrupt (because you have decided in a userspace policy that you want
> this), and then check to see if the packet count has changed. If it has,
> abort the suspend, if not continue the suspend and once you are suspended if
> the 'wake me up' interrupt is set you will wake back up.
>
> there are probably cleaner/better ways of doing this than the simple logic
> that I'm listing, but why wouldn't the simple logic provide the correct
> result?
If your network interrupt happens before the network driver's
suspend() hook is called this works -- the check in the suspend hook
observes the change and returns an abort status.
If your network interrupt happens after the suspend() hook is called
this does not work -- the event comes after your opportunity to abort
suspend has happened, your interrupt handler processed it, set the
flag, but the system proceeds to suspend anyway, missing the event.
The wakelock/suspendblock mechanism avoids races like the above.
Brian
On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> 2010/8/4 Rafael J. Wysocki <[email protected]>:
> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >> >> > No! And that's precisely the issue. Android's existing behaviour could
> >> >> > be entirely implemented in the form of binary that manually triggers
> >> >> > suspend when (a) the screen is off and (b) no userspace applications
> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
> >> >> > event race. Imagine the following:
> >> >> >
> >> >> > 1) The policy timeout is about to expire. No applications are holding
> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
> >> >> > 2) A network packet arrives indicating an incoming SIP call
> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
> >> >> > suspending while the call is in progress
> >> >> >
> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> >> >> > because the voip app is an otherwise untrusted application that you've
> >> >> > just told the scheduler to ignore.
> >> >>
> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
> >> >
> >> > Yes, I think that solves the problem. The only question then is whether
> >>
> >> How? By passing a timeout to pm_wakeup_event when the network driver
> >> gets the packet or by passing 0. If you pass a timeout it is the same
> >> as using a wakelock with a timeout and should work (assuming the
> >> timeout you picked is long enough). If you don't pass a timeout it
> >> does not work, since the packet may not be visible to user-space yet.
> >
> > Alternatively, pm_stay_awake() / pm_relax() can be used.
> >
>
> Which makes the driver and/or network stack changes identical to using
> wakelocks, right?
Please refer to the Matthew's response.
> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
> >> > to the implementation. In other words, is there a reason we're still
> >>
> >> I have seen no proposed way to use cgroups that will work. If you
> >> leave some processes running while other processes are frozen you run
> >> into problems when a frozen process holds a resource that a running
> >> process needs.
> >>
> >>
> >> > having this conversation? :) It'd be good to have some feedback from
> >> > Google as to whether this satisfies their functional requirements.
> >> >
> >>
> >> That is "this"? The merged code? If so, no it does not satisfy our
> >> requirements. The in kernel api, while offering similar functionality
> >> to the wakelock interface, does not use any handles which makes it
> >> impossible to get reasonable stats (You don't know which pm_stay_awake
> >> request pm_relax is reverting).
> >
> > Why is that a problem (out of curiosity)?
> >
>
> Not having stats or not knowing what pm_relax is undoing? We need
> stats to be able to debug the system.
You have the stats in struct device and they are available via sysfs.
I suppose they are insufficient, but I'd like to know why exactly.
> If the system does not suspend
> at all or is awake for too long, the wakelock stats tells us which
> component is at fault. Since pm_stay_awake and pm_relax does not
> operate on a handle, you cannot determine how long it prevented
> suspend for.
Well, if you need that, you can add a counter of "completed events" into
struct dev_pm_info and a function similar to pm_relax() that
will update that counter. I don't think anyone will object to that change.
> >> The proposed in user-space interface
> >> of calling into every process that receives wakeup events before every
> >> suspend call
> >
> > Well, you don't really need to do that.
> >
>
> Only if the driver blocks suspend until user-space has read the event.
> This means that for android to work we need to block suspend when
> input events are not processed, but a system using your scheme needs a
> pm_wakeup_event call when the input event is queued. How to you switch
> between them? Do we add separate ioctls in the input device to enable
> each scheme? If someone has a single threaded user space power manager
> that also reads input event it will deadlock if you block suspend
> until it reads the input events since you block when reading the wake
> count.
Well, until someone actually tries to implement a power manager in user space
it's a bit vague.
Thanks,
Rafael
On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>
> [ . . . ]
>
>>>>> The music player is an interesting example. It would be idle most
>>>>> of the time, given that audio output doesn't consume very much CPU.
>>>>> So you would not want to suspend the system just because there were
>>>>> no runnable processes. In contrast, allowing the music player to
>>>>> hold a wake lock lets the system know that it would not be appropriate
>>>>> to suspend.
>>>>>
>>>>> Or am I misunderstanding what you are proposing?
>>>>
>>>> the system would need to be idle for 'long enough' (configurable)
>>>> before deciding to suspend, so as long as 'long enough' is longer
>>>> than the music player is idle this would not be a problem.
>>>
>>> From a user standpoint, having the music player tell the system when
>>> it is OK to suspend (e.g., when the user has paused playback) seems
>>> a lot nicer than having configurable timeouts that need tweaking.
>>
>> every system that I have seen has a configurable "sleep if it's idle
>> for this long" knob. On the iphone (work issue, I didn't want it)
>> that I am currently using it can be configured from 1 min to 5 min.
>>
>> this is the sort of timeout I am talking about.
>>
>> with something in the multi-minute range for the 'do a full suspend'
>> doing a wakeup every few 10s of seconds is perfectly safe.
>
> Ah, I was assuming -much- shorter "do full suspend" timeouts.
>
> My (possibly incorrect) assumption is based on the complaint that led
> to my implementing RCU_FAST_NO_HZ. A (non-Android) embedded person was
> quite annoyed (to put it mildly) at the earlier version of RCU because
> it prevented the system from entering the power-saving dyntick-idle mode,
> not for minutes, or even for seconds, but for a handful of -milliseconds-.
> This was my first hint that "energy efficiency" means something completely
> different in embedded systems than it does in the servers that I am
> used to.
>
> But I must defer to the Android guys on this -- who knows, perhaps
> multi-minute delays to enter full-suspend mode are OK for them.
if the system was looking at all applications I would agree that the
timeout should be much shorter.
I have a couple devices that are able to have the display usable, even if
the CPU is asleep (the OLPC and the Kindle, two different display
technologies). With these devices I would like to see the suspend happen
so fast that it can suspend between keystrokes.
however, in the case of Android I think the timeouts have to end up being
_much_ longer. Otherwise you have the problem of loading an untrusted book
reader app on the device and the device suspends while you are reading the
page.
currently Android works around this by having a wakelock held whenever the
display is on. This seems backwards to me, the display should be on
because the system is not suspended, not the system is prevented from
suspending because the display is on.
Rather than having the display be on causing a wavelock to be held (with
the code that is controls the display having a timeout for how long it
leaves the display on), I would invert this and have the timeout be based
on system activity, and when it decides the system is not active, turn off
the display (along with other things as it suspends)
>>>>>> if the backlight being on holds the wakelock, it would seem that
>>>>>> almost every other use of the wakelock could (and probably should)
>>>>>> be replaced by something that tickles the display to stay on longer.
>>>>>
>>>>> The problem with this approach is that the display consumes quite a
>>>>> bit of power, so you don't want to leave it on unnecessarily. So if
>>>>> the system is doing something (for example, playing music) that does
>>>>> not require the display, you really want the display to be off.
>>>>
>>>> what percentage (and types) of apps are really useful with the
>>>> display off. I think that there are relativly few apps that you
>>>> really want to keep running if the display is off.
>>>
>>> The length of time those apps are running is the governing factor
>>> for battery life, and not the number of such apps, right?
>>
>> correct, but the number of such apps indicates the scope of the problem.
>
> The number of such apps certainly indicates the amount of effort required
> to modify them, if required. Is that what you are getting at?
yes.
>>> From another e-mail tonight it sounds like almost everything
>>> already talks
>>
>> to a userspace daemon, so if "(the power management service in the
>> system_server, possibly the media_server and the radio interface
>> glue)" (plus possibly some kernel activity) are the only things
>> looked at when considering if it's safe to sleep or not, all of
>> these can (or already do) do 'something' every few seconds, making
>> this problem sound significantly smaller than it sounded like
>> before.
>>
>> Android could even keep it's user-space API between the system power
>> daemon and the rest of userspace the same if they want to.
>>
>> over time, additional apps could be considered 'trusted' (or flagged
>> that way by the user) and not have to interact with the power daemon
>> to keep things alive.
>
> Hmmm... Isn't it the "trusted" (AKA PM-driving) apps that interact with
> the power daemon via suspend blockers, rather than the other way around?
I was looking at it from a kernel point of view, "trusted" (AKA
PM-driving) apps are ones that have permission to grab the wakelock. Any
app/daemon that is so trusted can communicate with anything else in
userspace as part of making it's decision on whento take the wakelock, but
those other applications would not qualify as "trusted" in my eyes.
>> as for intramentation, the key tool to use to see why a system isn't
>> going to sleep would be powertop, just like on other linux systems.
>
> Powertop is indeed an extremely valuable tool, but I am not certain
> that it really provides the information that the Android guys need.
> If I understand Arve's and Brian's posts, here is the scenario that they
> are trying to detect:
>
> o Some PM-driving application has a bug in which it fails to
> release a wakelock, thus blocking suspend indefinitely.
>
> o This PM-driving application, otherwise being a good citizen,
> blocks.
>
> o There are numerous power-oblivious apps running, consuming
> significant CPU.
>
> What the Android developers need to know is that the trusted application
> is wrongly holding a wakelock. Won't powertop instead tell them about
> all the power-oblivious apps?
in my proposal (without a wakelock), powertop would tell you what
applications are running and setting timers. If we can modify the
kernel/suspend decision code to only look at processes in one cgroup when
deciding if the system should go to sleep, a similar modification to
poewrtop should let you only show stats on the "trusted" applications.
If you have a userspace power management daemon that accepts requests from
untrusted programs and does something to keep the system from sleeping
(either taking a wakelock or setting a 'short' timer), it needs to keep
the records of this itself because otherwise all the kernel will see (with
either powertop or wakelock reporting) is that the power management daemon
is what kept the system from sleeping.
David Lang
On Thu, Aug 05, 2010 at 08:12:11AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> > as for intramentation, the key tool to use to see why a system isn't
> > going to sleep would be powertop, just like on other linux systems.
> Powertop is indeed an extremely valuable tool, but I am not certain
> that it really provides the information that the Android guys need.
> If I understand Arve's and Brian's posts, here is the scenario that they
> are trying to detect:
> o Some PM-driving application has a bug in which it fails to
> release a wakelock, thus blocking suspend indefinitely.
> o This PM-driving application, otherwise being a good citizen,
> blocks.
> o There are numerous power-oblivious apps running, consuming
> significant CPU.
Or otherwise doing something power hungry.
> What the Android developers need to know is that the trusted application
> is wrongly holding a wakelock. Won't powertop instead tell them about
> all the power-oblivious apps?
Right, and this isn't just information for developers - Android handsets
expose this information to end users (so they can indentify any badly
behaved applications they have installed or otherwise modify their
handset usage if they are disappointed by their battery life). That
said, powertop and similar applications could always be extended to also
include data from wakelocks.
On Thu, Aug 05, 2010 at 08:46:54AM -0700, [email protected] wrote:
> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>
> >On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> >>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >
> >[ . . . ]
> >
> >>>>>The music player is an interesting example. It would be idle most
> >>>>>of the time, given that audio output doesn't consume very much CPU.
> >>>>>So you would not want to suspend the system just because there were
> >>>>>no runnable processes. In contrast, allowing the music player to
> >>>>>hold a wake lock lets the system know that it would not be appropriate
> >>>>>to suspend.
> >>>>>
> >>>>>Or am I misunderstanding what you are proposing?
> >>>>
> >>>>the system would need to be idle for 'long enough' (configurable)
> >>>>before deciding to suspend, so as long as 'long enough' is longer
> >>>>than the music player is idle this would not be a problem.
> >>>
> >>>From a user standpoint, having the music player tell the system when
> >>>it is OK to suspend (e.g., when the user has paused playback) seems
> >>>a lot nicer than having configurable timeouts that need tweaking.
> >>
> >>every system that I have seen has a configurable "sleep if it's idle
> >>for this long" knob. On the iphone (work issue, I didn't want it)
> >>that I am currently using it can be configured from 1 min to 5 min.
> >>
> >>this is the sort of timeout I am talking about.
> >>
> >>with something in the multi-minute range for the 'do a full suspend'
> >>doing a wakeup every few 10s of seconds is perfectly safe.
> >
> >Ah, I was assuming -much- shorter "do full suspend" timeouts.
> >
> >My (possibly incorrect) assumption is based on the complaint that led
> >to my implementing RCU_FAST_NO_HZ. A (non-Android) embedded person was
> >quite annoyed (to put it mildly) at the earlier version of RCU because
> >it prevented the system from entering the power-saving dyntick-idle mode,
> >not for minutes, or even for seconds, but for a handful of -milliseconds-.
> >This was my first hint that "energy efficiency" means something completely
> >different in embedded systems than it does in the servers that I am
> >used to.
> >
> >But I must defer to the Android guys on this -- who knows, perhaps
> >multi-minute delays to enter full-suspend mode are OK for them.
>
> if the system was looking at all applications I would agree that the
> timeout should be much shorter.
>
> I have a couple devices that are able to have the display usable,
> even if the CPU is asleep (the OLPC and the Kindle, two different
> display technologies). With these devices I would like to see the
> suspend happen so fast that it can suspend between keystrokes.
>
> however, in the case of Android I think the timeouts have to end up
> being _much_ longer. Otherwise you have the problem of loading an
> untrusted book reader app on the device and the device suspends
> while you are reading the page.
>
> currently Android works around this by having a wakelock held
> whenever the display is on. This seems backwards to me, the display
> should be on because the system is not suspended, not the system is
> prevented from suspending because the display is on.
>
> Rather than having the display be on causing a wavelock to be held
> (with the code that is controls the display having a timeout for how
> long it leaves the display on), I would invert this and have the
> timeout be based on system activity, and when it decides the system
> is not active, turn off the display (along with other things as it
> suspends)
>From what I can see, the decision between these two approaches comes down
to their energy efficiencies, and thus their battery lifetimes. Are you
in a position to benchmark these two approaches against each other?
> >>>>>>if the backlight being on holds the wakelock, it would seem that
> >>>>>>almost every other use of the wakelock could (and probably should)
> >>>>>>be replaced by something that tickles the display to stay on longer.
> >>>>>
> >>>>>The problem with this approach is that the display consumes quite a
> >>>>>bit of power, so you don't want to leave it on unnecessarily. So if
> >>>>>the system is doing something (for example, playing music) that does
> >>>>>not require the display, you really want the display to be off.
> >>>>
> >>>>what percentage (and types) of apps are really useful with the
> >>>>display off. I think that there are relativly few apps that you
> >>>>really want to keep running if the display is off.
> >>>
> >>>The length of time those apps are running is the governing factor
> >>>for battery life, and not the number of such apps, right?
> >>
> >>correct, but the number of such apps indicates the scope of the problem.
> >
> >The number of such apps certainly indicates the amount of effort required
> >to modify them, if required. Is that what you are getting at?
>
> yes.
>
> >>>From another e-mail tonight it sounds like almost everything
> >>>already talks
> >>
> >>to a userspace daemon, so if "(the power management service in the
> >>system_server, possibly the media_server and the radio interface
> >>glue)" (plus possibly some kernel activity) are the only things
> >>looked at when considering if it's safe to sleep or not, all of
> >>these can (or already do) do 'something' every few seconds, making
> >>this problem sound significantly smaller than it sounded like
> >>before.
> >>
> >>Android could even keep it's user-space API between the system power
> >>daemon and the rest of userspace the same if they want to.
> >>
> >>over time, additional apps could be considered 'trusted' (or flagged
> >>that way by the user) and not have to interact with the power daemon
> >>to keep things alive.
> >
> >Hmmm... Isn't it the "trusted" (AKA PM-driving) apps that interact with
> >the power daemon via suspend blockers, rather than the other way around?
>
> I was looking at it from a kernel point of view, "trusted" (AKA
> PM-driving) apps are ones that have permission to grab the wakelock.
> Any app/daemon that is so trusted can communicate with anything else
> in userspace as part of making it's decision on whento take the
> wakelock, but those other applications would not qualify as
> "trusted" in my eyes.
So you are saying that PM-driving apps can check up on power-oblivious
apps as part of their decision process. Sounds reasonable to me,
though such checking increases the dependencies among apps, which might
increase complexity.
> >>as for intramentation, the key tool to use to see why a system isn't
> >>going to sleep would be powertop, just like on other linux systems.
> >
> >Powertop is indeed an extremely valuable tool, but I am not certain
> >that it really provides the information that the Android guys need.
> >If I understand Arve's and Brian's posts, here is the scenario that they
> >are trying to detect:
> >
> >o Some PM-driving application has a bug in which it fails to
> > release a wakelock, thus blocking suspend indefinitely.
> >
> >o This PM-driving application, otherwise being a good citizen,
> > blocks.
> >
> >o There are numerous power-oblivious apps running, consuming
> > significant CPU.
> >
> >What the Android developers need to know is that the trusted application
> >is wrongly holding a wakelock. Won't powertop instead tell them about
> >all the power-oblivious apps?
>
> in my proposal (without a wakelock), powertop would tell you what
> applications are running and setting timers. If we can modify the
> kernel/suspend decision code to only look at processes in one cgroup
> when deciding if the system should go to sleep, a similar
> modification to poewrtop should let you only show stats on the
> "trusted" applications.
Mark Brown suggests adding suspend-blocker information to powertop, which
might well be a very good way to handle this. This sounds plausible to
me, but then again, I have never chased down wakelock bugs on Android
systems.
A key point is that it is not enough to focus on PM-driving apps, you
instead need to focus on only those PM-driving apps that currently hold
a suspend blocker.
> If you have a userspace power management daemon that accepts
> requests from untrusted programs and does something to keep the
> system from sleeping (either taking a wakelock or setting a 'short'
> timer), it needs to keep the records of this itself because
> otherwise all the kernel will see (with either powertop or wakelock
> reporting) is that the power management daemon is what kept the
> system from sleeping.
According to Brian Swetland, Android does in fact have such a
power-management daemon. I would guess that this daemon tracks which
apps it is holding suspend blockers on behalf of. This approach might
well make it harder to bring powertop to bear, as powertop would need
to communicate with Android's power-management daemon. But perhaps
something could be arranged.
Thanx, Paul
On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>
>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>>>
>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>>>
>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>
>> [ . . . ]
>>
>>>>>> The music player is an interesting example. ?It would be idle most
>>>>>> of the time, given that audio output doesn't consume very much CPU.
>>>>>> So you would not want to suspend the system just because there were
>>>>>> no runnable processes. ?In contrast, allowing the music player to
>>>>>> hold a wake lock lets the system know that it would not be appropriate
>>>>>> to suspend.
>>>>>>
>>>>>> Or am I misunderstanding what you are proposing?
>>>>>
>>>>> the system would need to be idle for 'long enough' (configurable)
>>>>> before deciding to suspend, so as long as 'long enough' is longer
>>>>> than the music player is idle this would not be a problem.
>>>>
>>>> From a user standpoint, having the music player tell the system when
>>>> it is OK to suspend (e.g., when the user has paused playback) seems
>>>> a lot nicer than having configurable timeouts that need tweaking.
>>>
>>> every system that I have seen has a configurable "sleep if it's idle
>>> for this long" knob. On the iphone (work issue, I didn't want it)
>>> that I am currently using it can be configured from 1 min to 5 min.
>>>
>>> this is the sort of timeout I am talking about.
>>>
>>> with something in the multi-minute range for the 'do a full suspend'
>>> doing a wakeup every few 10s of seconds is perfectly safe.
>>
>> Ah, I was assuming -much- shorter "do full suspend" timeouts.
>>
>> My (possibly incorrect) assumption is based on the complaint that led
>> to my implementing RCU_FAST_NO_HZ. ?A (non-Android) embedded person was
>> quite annoyed (to put it mildly) at the earlier version of RCU because
>> it prevented the system from entering the power-saving dyntick-idle mode,
>> not for minutes, or even for seconds, but for a handful of -milliseconds-.
>> This was my first hint that "energy efficiency" means something completely
>> different in embedded systems than it does in the servers that I am
>> used to.
>>
>> But I must defer to the Android guys on this -- who knows, perhaps
>> multi-minute delays to enter full-suspend mode are OK for them.
>
> if the system was looking at all applications I would agree that the timeout
> should be much shorter.
>
> I have a couple devices that are able to have the display usable, even if
> the CPU is asleep (the OLPC and the Kindle, two different display
> technologies). With these devices I would like to see the suspend happen so
> fast that it can suspend between keystrokes.
>
> however, in the case of Android I think the timeouts have to end up being
> _much_ longer. Otherwise you have the problem of loading an untrusted book
> reader app on the device and the device suspends while you are reading the
> page.
>
> currently Android works around this by having a wakelock held whenever the
> display is on. This seems backwards to me, the display should be on because
> the system is not suspended, not the system is prevented from suspending
> because the display is on.
>
> Rather than having the display be on causing a wavelock to be held (with the
> code that is controls the display having a timeout for how long it leaves
> the display on), I would invert this and have the timeout be based on system
> activity, and when it decides the system is not active, turn off the display
> (along with other things as it suspends)
IIRC, this was a major point of their (Android's) power management
policy. User input of any kind would reset the "display active"
timeout, which is the primary thing keeping random untrusted
user-facing programs from being suspended while in use. They seemed
to consider this to be a special case in their policy, but from the
kernel's point of view it is just another suspend blocker being held.
I'm not sure this is the best use case to look at though, because
since it is user-facing, the timeout durations are on a different
scale than the ones they are really worried about. I think another
category of use case that they are worried about is:
(in suspend) -> wakeup due to network -> process network activity -> suspend
or an example that has been mentioned previously:
(in suspend) -> wakeup due to alarm for audio processing -> process
batch of audio -> suspend
In both of these cases, the display may never power on (phone might
beep to indicate txt message or email, audio just keeps playing), so
the magnitude of the "timeout" for suspending again should be very
small. Specifically, they don't want there to be a timeout at all, so
as little time as possible time is spent out of suspend in addition to
the time required to handle the event that caused wakeup.
>
>>>>>>> if the backlight being on holds the wakelock, it would seem that
>>>>>>> almost every other use of the wakelock could (and probably should)
>>>>>>> be replaced by something that tickles the display to stay on longer.
>>>>>>
>>>>>> The problem with this approach is that the display consumes quite a
>>>>>> bit of power, so you don't want to leave it on unnecessarily. ?So if
>>>>>> the system is doing something (for example, playing music) that does
>>>>>> not require the display, you really want the display to be off.
>>>>>
>>>>> what percentage (and types) of apps are really useful with the
>>>>> display off. I think that there are relativly few apps that you
>>>>> really want to keep running if the display is off.
>>>>
>>>> The length of time those apps are running is the governing factor
>>>> for battery life, and not the number of such apps, right?
>>>
>>> correct, but the number of such apps indicates the scope of the problem.
>>
>> The number of such apps certainly indicates the amount of effort required
>> to modify them, if required. ?Is that what you are getting at?
>
> yes.
>
>>>> From another e-mail tonight it sounds like almost everything
>>>> already talks
>>>
>>> to a userspace daemon, so if "(the power management service in the
>>> system_server, possibly the media_server and the radio interface
>>> glue)" (plus possibly some kernel activity) are the only things
>>> looked at when considering if it's safe to sleep or not, all of
>>> these can (or already do) do 'something' every few seconds, making
>>> this problem sound significantly smaller than it sounded like
>>> before.
>>>
>>> Android could even keep it's user-space API between the system power
>>> daemon and the rest of userspace the same if they want to.
>>>
>>> over time, additional apps could be considered 'trusted' (or flagged
>>> that way by the user) and not have to interact with the power daemon
>>> to keep things alive.
>>
>> Hmmm... ?Isn't it the "trusted" (AKA PM-driving) apps that interact with
>> the power daemon via suspend blockers, rather than the other way around?
>
> I was looking at it from a kernel point of view, "trusted" (AKA PM-driving)
> apps are ones that have permission to grab the wakelock. Any app/daemon that
> is so trusted can communicate with anything else in userspace as part of
> making it's decision on whento take the wakelock, but those other
> applications would not qualify as "trusted" in my eyes.
>
>>> as for intramentation, the key tool to use to see why a system isn't
>>> going to sleep would be powertop, just like on other linux systems.
>>
>> Powertop is indeed an extremely valuable tool, but I am not certain
>> that it really provides the information that the Android guys need.
>> If I understand Arve's and Brian's posts, here is the scenario that they
>> are trying to detect:
>>
>> o ? ? ? Some PM-driving application has a bug in which it fails to
>> ? ? ? ?release a wakelock, thus blocking suspend indefinitely.
>>
>> o ? ? ? This PM-driving application, otherwise being a good citizen,
>> ? ? ? ?blocks.
>>
>> o ? ? ? There are numerous power-oblivious apps running, consuming
>> ? ? ? ?significant CPU.
>>
>> What the Android developers need to know is that the trusted application
>> is wrongly holding a wakelock. ?Won't powertop instead tell them about
>> all the power-oblivious apps?
>
> in my proposal (without a wakelock), powertop would tell you what
> applications are running and setting timers. If we can modify the
> kernel/suspend decision code to only look at processes in one cgroup when
> deciding if the system should go to sleep, a similar modification to
> poewrtop should let you only show stats on the "trusted" applications.
>
> If you have a userspace power management daemon that accepts requests from
> untrusted programs and does something to keep the system from sleeping
> (either taking a wakelock or setting a 'short' timer), it needs to keep the
> records of this itself because otherwise all the kernel will see (with
> either powertop or wakelock reporting) is that the power management daemon
> is what kept the system from sleeping.
>
> David Lang
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Thu, Aug 5, 2010 at 11:13 AM, kevin granade <[email protected]> wrote:
> IIRC, this was a major point of their (Android's) power management
> policy. User input of any kind would reset the "display active"
> timeout, which is the primary thing keeping random untrusted
> user-facing programs from being suspended while in use. They seemed
> to consider this to be a special case in their policy, but from the
> kernel's point of view it is just another suspend blocker being held.
The display being on should not prevent suspend unless the particular
platform is incapable of suspending while the display is on.
> I'm not sure this is the best use case to look at though, because
> since it is user-facing, the timeout durations are on a different
> scale than the ones they are really worried about. I think another
> category of use case that they are worried about is:
>
> (in suspend) -> wakeup due to network -> process network activity -> suspend
>
> or an example that has been mentioned previously:
>
> (in suspend) -> wakeup due to alarm for audio processing -> process
> batch of audio -> suspend
>
> In both of these cases, the display may never power on (phone might
> beep to indicate txt message or email, audio just keeps playing), so
> the magnitude of the "timeout" for suspending again should be very
> small. Specifically, they don't want there to be a timeout at all, so
> as little time as possible time is spent out of suspend in addition to
> the time required to handle the event that caused wakeup.
Yeah, we much prefer the wakelock model where the moment the resource
(system-needing-to-not-be-suspended) is released we return to the
lowest power state, rather than waiting for a timer to expire (and/or
burning cycles polling for "can we suspend yet?" when we're definitely
not ready to suspend).
Brian
On Thu, Aug 05, 2010 at 05:09:17PM +0100, Mark Brown wrote:
> On Thu, Aug 05, 2010 at 08:12:11AM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>
> > > as for intramentation, the key tool to use to see why a system isn't
> > > going to sleep would be powertop, just like on other linux systems.
>
> > Powertop is indeed an extremely valuable tool, but I am not certain
> > that it really provides the information that the Android guys need.
> > If I understand Arve's and Brian's posts, here is the scenario that they
> > are trying to detect:
>
> > o Some PM-driving application has a bug in which it fails to
> > release a wakelock, thus blocking suspend indefinitely.
>
> > o This PM-driving application, otherwise being a good citizen,
> > blocks.
>
> > o There are numerous power-oblivious apps running, consuming
> > significant CPU.
>
> Or otherwise doing something power hungry.
>
> > What the Android developers need to know is that the trusted application
> > is wrongly holding a wakelock. Won't powertop instead tell them about
> > all the power-oblivious apps?
>
> Right, and this isn't just information for developers - Android handsets
> expose this information to end users (so they can indentify any badly
> behaved applications they have installed or otherwise modify their
> handset usage if they are disappointed by their battery life). That
> said, powertop and similar applications could always be extended to also
> include data from wakelocks.
Good point!!! Of course, powertop would need to interact with Android's
user-level daemon for this to work, but perhaps this could be arranged.
(There is a user-level daemon in Android that acquires kernel-level
suspend blockers on behalf of applications, so a naive mod to powertop
would just finger the user-level daemon.)
Thanx, Paul
On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> Subject: Re: Attempted summary of suspend-blockers LKML thread
>
> On Thu, Aug 05, 2010 at 08:46:54AM -0700, [email protected] wrote:
>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>
>>> [ . . . ]
>>>
>>>>>>> The music player is an interesting example. It would be idle most
>>>>>>> of the time, given that audio output doesn't consume very much CPU.
>>>>>>> So you would not want to suspend the system just because there were
>>>>>>> no runnable processes. In contrast, allowing the music player to
>>>>>>> hold a wake lock lets the system know that it would not be appropriate
>>>>>>> to suspend.
>>>>>>>
>>>>>>> Or am I misunderstanding what you are proposing?
>>>>>>
>>>>>> the system would need to be idle for 'long enough' (configurable)
>>>>>> before deciding to suspend, so as long as 'long enough' is longer
>>>>>> than the music player is idle this would not be a problem.
>>>>>
>>>>> From a user standpoint, having the music player tell the system when
>>>>> it is OK to suspend (e.g., when the user has paused playback) seems
>>>>> a lot nicer than having configurable timeouts that need tweaking.
>>>>
>>>> every system that I have seen has a configurable "sleep if it's idle
>>>> for this long" knob. On the iphone (work issue, I didn't want it)
>>>> that I am currently using it can be configured from 1 min to 5 min.
>>>>
>>>> this is the sort of timeout I am talking about.
>>>>
>>>> with something in the multi-minute range for the 'do a full suspend'
>>>> doing a wakeup every few 10s of seconds is perfectly safe.
>>>
>>> Ah, I was assuming -much- shorter "do full suspend" timeouts.
>>>
>>> My (possibly incorrect) assumption is based on the complaint that led
>>> to my implementing RCU_FAST_NO_HZ. A (non-Android) embedded person was
>>> quite annoyed (to put it mildly) at the earlier version of RCU because
>>> it prevented the system from entering the power-saving dyntick-idle mode,
>>> not for minutes, or even for seconds, but for a handful of -milliseconds-.
>>> This was my first hint that "energy efficiency" means something completely
>>> different in embedded systems than it does in the servers that I am
>>> used to.
>>>
>>> But I must defer to the Android guys on this -- who knows, perhaps
>>> multi-minute delays to enter full-suspend mode are OK for them.
>>
>> if the system was looking at all applications I would agree that the
>> timeout should be much shorter.
>>
>> I have a couple devices that are able to have the display usable,
>> even if the CPU is asleep (the OLPC and the Kindle, two different
>> display technologies). With these devices I would like to see the
>> suspend happen so fast that it can suspend between keystrokes.
>>
>> however, in the case of Android I think the timeouts have to end up
>> being _much_ longer. Otherwise you have the problem of loading an
>> untrusted book reader app on the device and the device suspends
>> while you are reading the page.
>>
>> currently Android works around this by having a wakelock held
>> whenever the display is on. This seems backwards to me, the display
>> should be on because the system is not suspended, not the system is
>> prevented from suspending because the display is on.
>>
>> Rather than having the display be on causing a wavelock to be held
>> (with the code that is controls the display having a timeout for how
>> long it leaves the display on), I would invert this and have the
>> timeout be based on system activity, and when it decides the system
>> is not active, turn off the display (along with other things as it
>> suspends)
>
> From what I can see, the decision between these two approaches comes down
> to their energy efficiencies, and thus their battery lifetimes. Are you
> in a position to benchmark these two approaches against each other?
no, I'm not in a position to benchmark them against each other.
I am claiming that (in this area) the two are equivalent (or at lease very
close to equivalent given the approximate magnatude of the timeouts that
are involved)
1. a daemon controls the screen, monitors input and holds a wakelock until
a configurable timeout after input, after which the system sleeps
2. a daemon monitors input, it wakes up every few seconds (to 10s of
seconds) when there is no input for a configurable timeout the daemon
sleep without waking up periodically. when the daemon sleeps for longer
than a configurable period the system is considered idle and goes to
sleep.
in both cases the system will be awake as long as there is input within
the initial timeout period.
the second case could eata smidge power as there can be an additional lag
before the system sleeps (the second timeout), that depends on exactly how
the input is detected.
>>>>> From another e-mail tonight it sounds like almost everything
>>>>> already talks
>>>>
>>>> to a userspace daemon, so if "(the power management service in the
>>>> system_server, possibly the media_server and the radio interface
>>>> glue)" (plus possibly some kernel activity) are the only things
>>>> looked at when considering if it's safe to sleep or not, all of
>>>> these can (or already do) do 'something' every few seconds, making
>>>> this problem sound significantly smaller than it sounded like
>>>> before.
>>>>
>>>> Android could even keep it's user-space API between the system power
>>>> daemon and the rest of userspace the same if they want to.
>>>>
>>>> over time, additional apps could be considered 'trusted' (or flagged
>>>> that way by the user) and not have to interact with the power daemon
>>>> to keep things alive.
>>>
>>> Hmmm... Isn't it the "trusted" (AKA PM-driving) apps that interact with
>>> the power daemon via suspend blockers, rather than the other way around?
>>
>> I was looking at it from a kernel point of view, "trusted" (AKA
>> PM-driving) apps are ones that have permission to grab the wakelock.
>> Any app/daemon that is so trusted can communicate with anything else
>> in userspace as part of making it's decision on whento take the
>> wakelock, but those other applications would not qualify as
>> "trusted" in my eyes.
>
> So you are saying that PM-driving apps can check up on power-oblivious
> apps as part of their decision process. Sounds reasonable to me,
> though such checking increases the dependencies among apps, which might
> increase complexity.
more to the point, I'm saying that that's how it works currently with
wavelocks. the unprivilaged processes can ask the privilaged process to
hold a wavelock for them.
>>>> as for intramentation, the key tool to use to see why a system isn't
>>>> going to sleep would be powertop, just like on other linux systems.
>>>
>>> Powertop is indeed an extremely valuable tool, but I am not certain
>>> that it really provides the information that the Android guys need.
>>> If I understand Arve's and Brian's posts, here is the scenario that they
>>> are trying to detect:
>>>
>>> o Some PM-driving application has a bug in which it fails to
>>> release a wakelock, thus blocking suspend indefinitely.
>>>
>>> o This PM-driving application, otherwise being a good citizen,
>>> blocks.
>>>
>>> o There are numerous power-oblivious apps running, consuming
>>> significant CPU.
>>>
>>> What the Android developers need to know is that the trusted application
>>> is wrongly holding a wakelock. Won't powertop instead tell them about
>>> all the power-oblivious apps?
>>
>> in my proposal (without a wakelock), powertop would tell you what
>> applications are running and setting timers. If we can modify the
>> kernel/suspend decision code to only look at processes in one cgroup
>> when deciding if the system should go to sleep, a similar
>> modification to poewrtop should let you only show stats on the
>> "trusted" applications.
>
> Mark Brown suggests adding suspend-blocker information to powertop, which
> might well be a very good way to handle this. This sounds plausible to
> me, but then again, I have never chased down wakelock bugs on Android
> systems.
>
> A key point is that it is not enough to focus on PM-driving apps, you
> instead need to focus on only those PM-driving apps that currently hold
> a suspend blocker.
if you have wavelocks, then you just need info on the use of wavelocks
with my proposal staying awake is based on process activity, which is
exactly what powertop is monitoring now, it just needs to be able to
filter out the activity of the untrusted apps.
>> If you have a userspace power management daemon that accepts
>> requests from untrusted programs and does something to keep the
>> system from sleeping (either taking a wakelock or setting a 'short'
>> timer), it needs to keep the records of this itself because
>> otherwise all the kernel will see (with either powertop or wakelock
>> reporting) is that the power management daemon is what kept the
>> system from sleeping.
>
> According to Brian Swetland, Android does in fact have such a
> power-management daemon. I would guess that this daemon tracks which
> apps it is holding suspend blockers on behalf of. This approach might
> well make it harder to bring powertop to bear, as powertop would need
> to communicate with Android's power-management daemon. But perhaps
> something could be arranged.
My expectation is that instead of modifying apps to talk to the power
management daemon, the apps would be classified as 'trusted' or
'untrusted' more appropriatly.
if user input is activity that keeps the system alive, then only
applications that will run for extended period with no user input need to
be trusted.
David Lang
On Thu, 5 Aug 2010, kevin granade wrote:
> On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>>>>
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>>>>
>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>
>>> [ . . . ]
>>>
>> however, in the case of Android I think the timeouts have to end up being
>> _much_ longer. Otherwise you have the problem of loading an untrusted book
>> reader app on the device and the device suspends while you are reading the
>> page.
>>
>> currently Android works around this by having a wakelock held whenever the
>> display is on. This seems backwards to me, the display should be on because
>> the system is not suspended, not the system is prevented from suspending
>> because the display is on.
>>
>> Rather than having the display be on causing a wavelock to be held (with the
>> code that is controls the display having a timeout for how long it leaves
>> the display on), I would invert this and have the timeout be based on system
>> activity, and when it decides the system is not active, turn off the display
>> (along with other things as it suspends)
>
> IIRC, this was a major point of their (Android's) power management
> policy. User input of any kind would reset the "display active"
> timeout, which is the primary thing keeping random untrusted
> user-facing programs from being suspended while in use. They seemed
> to consider this to be a special case in their policy, but from the
> kernel's point of view it is just another suspend blocker being held.
>
> I'm not sure this is the best use case to look at though, because
> since it is user-facing, the timeout durations are on a different
> scale than the ones they are really worried about. I think another
> category of use case that they are worried about is:
>
> (in suspend) -> wakeup due to network -> process network activity -> suspend
>
> or an example that has been mentioned previously:
>
> (in suspend) -> wakeup due to alarm for audio processing -> process
> batch of audio -> suspend
when you suspend the audio will shut off, so it's sleep ->wake -> sleep,
not suspend
> In both of these cases, the display may never power on (phone might
> beep to indicate txt message or email, audio just keeps playing), so
> the magnitude of the "timeout" for suspending again should be very
> small. Specifically, they don't want there to be a timeout at all, so
> as little time as possible time is spent out of suspend in addition to
> the time required to handle the event that caused wakeup.
it really depnds on the frequency of the wakeups.
if you get a network packet once every 5 min and need to wake to process
it, staying awake for 20 seconds after finishing procesing is FAR more
significant than if you get a network packet once every hour. It's not
just the factor of 20 that simple math would indicate because the time in
suspend eats power as well.
I don't know real numbers, so these are made up for this example
if suspend (with the cell live to receive packets) is 10ma average current
and full power is 500ma average current
packets every 5 min with .1 sec wake time will eat ~13maH per hour
packets every 5 min with 10 second wake time will eat ~37maH per hour
packets every hour with .1 sec wake time will eat ~10maH per hour
packets every hour with 10 sec wake time will eat ~11maH per hour
so if you have frequent wakeups, staying awake 100 times as long will cut
your battery life to 1/3 what it was before.
if your wakeups are rare, it's about a 10% hit to stay awake 100 times as
long.
there is a lot of room for tuning the timeouts here.
David Lang
On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:
> On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
> > On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> >
> >> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> >>>
> >>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>>
> >>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >>>>>
> >>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>
> >> [ . . . ]
> >>
> >>>>>> The music player is an interesting example. ?It would be idle most
> >>>>>> of the time, given that audio output doesn't consume very much CPU.
> >>>>>> So you would not want to suspend the system just because there were
> >>>>>> no runnable processes. ?In contrast, allowing the music player to
> >>>>>> hold a wake lock lets the system know that it would not be appropriate
> >>>>>> to suspend.
> >>>>>>
> >>>>>> Or am I misunderstanding what you are proposing?
> >>>>>
> >>>>> the system would need to be idle for 'long enough' (configurable)
> >>>>> before deciding to suspend, so as long as 'long enough' is longer
> >>>>> than the music player is idle this would not be a problem.
> >>>>
> >>>> From a user standpoint, having the music player tell the system when
> >>>> it is OK to suspend (e.g., when the user has paused playback) seems
> >>>> a lot nicer than having configurable timeouts that need tweaking.
> >>>
> >>> every system that I have seen has a configurable "sleep if it's idle
> >>> for this long" knob. On the iphone (work issue, I didn't want it)
> >>> that I am currently using it can be configured from 1 min to 5 min.
> >>>
> >>> this is the sort of timeout I am talking about.
> >>>
> >>> with something in the multi-minute range for the 'do a full suspend'
> >>> doing a wakeup every few 10s of seconds is perfectly safe.
> >>
> >> Ah, I was assuming -much- shorter "do full suspend" timeouts.
> >>
> >> My (possibly incorrect) assumption is based on the complaint that led
> >> to my implementing RCU_FAST_NO_HZ. ?A (non-Android) embedded person was
> >> quite annoyed (to put it mildly) at the earlier version of RCU because
> >> it prevented the system from entering the power-saving dyntick-idle mode,
> >> not for minutes, or even for seconds, but for a handful of -milliseconds-.
> >> This was my first hint that "energy efficiency" means something completely
> >> different in embedded systems than it does in the servers that I am
> >> used to.
> >>
> >> But I must defer to the Android guys on this -- who knows, perhaps
> >> multi-minute delays to enter full-suspend mode are OK for them.
> >
> > if the system was looking at all applications I would agree that the timeout
> > should be much shorter.
> >
> > I have a couple devices that are able to have the display usable, even if
> > the CPU is asleep (the OLPC and the Kindle, two different display
> > technologies). With these devices I would like to see the suspend happen so
> > fast that it can suspend between keystrokes.
> >
> > however, in the case of Android I think the timeouts have to end up being
> > _much_ longer. Otherwise you have the problem of loading an untrusted book
> > reader app on the device and the device suspends while you are reading the
> > page.
> >
> > currently Android works around this by having a wakelock held whenever the
> > display is on. This seems backwards to me, the display should be on because
> > the system is not suspended, not the system is prevented from suspending
> > because the display is on.
> >
> > Rather than having the display be on causing a wavelock to be held (with the
> > code that is controls the display having a timeout for how long it leaves
> > the display on), I would invert this and have the timeout be based on system
> > activity, and when it decides the system is not active, turn off the display
> > (along with other things as it suspends)
>
> IIRC, this was a major point of their (Android's) power management
> policy. User input of any kind would reset the "display active"
> timeout, which is the primary thing keeping random untrusted
> user-facing programs from being suspended while in use. They seemed
> to consider this to be a special case in their policy, but from the
> kernel's point of view it is just another suspend blocker being held.
>
> I'm not sure this is the best use case to look at though, because
> since it is user-facing, the timeout durations are on a different
> scale than the ones they are really worried about. I think another
> category of use case that they are worried about is:
>
> (in suspend) -> wakeup due to network -> process network activity -> suspend
>
> or an example that has been mentioned previously:
>
> (in suspend) -> wakeup due to alarm for audio processing -> process
> batch of audio -> suspend
>
> In both of these cases, the display may never power on (phone might
> beep to indicate txt message or email, audio just keeps playing), so
> the magnitude of the "timeout" for suspending again should be very
> small. Specifically, they don't want there to be a timeout at all, so
> as little time as possible time is spent out of suspend in addition to
> the time required to handle the event that caused wakeup.
It would be good to get some sort of range for the "timeout". In the
audio-output case, my understanding that the spacing between bursts of
audio-processing activity is measured in some hundreds of milliseconds,
in which case one would want the delays until suspend to be on the
millisecond scale. But does Android really suspend between bursts of
audio processing while playing music? Very cool if so! ;-)
Thanx, Paul
> >>>>>>> if the backlight being on holds the wakelock, it would seem that
> >>>>>>> almost every other use of the wakelock could (and probably should)
> >>>>>>> be replaced by something that tickles the display to stay on longer.
> >>>>>>
> >>>>>> The problem with this approach is that the display consumes quite a
> >>>>>> bit of power, so you don't want to leave it on unnecessarily. ?So if
> >>>>>> the system is doing something (for example, playing music) that does
> >>>>>> not require the display, you really want the display to be off.
> >>>>>
> >>>>> what percentage (and types) of apps are really useful with the
> >>>>> display off. I think that there are relativly few apps that you
> >>>>> really want to keep running if the display is off.
> >>>>
> >>>> The length of time those apps are running is the governing factor
> >>>> for battery life, and not the number of such apps, right?
> >>>
> >>> correct, but the number of such apps indicates the scope of the problem.
> >>
> >> The number of such apps certainly indicates the amount of effort required
> >> to modify them, if required. ?Is that what you are getting at?
> >
> > yes.
> >
> >>>> From another e-mail tonight it sounds like almost everything
> >>>> already talks
> >>>
> >>> to a userspace daemon, so if "(the power management service in the
> >>> system_server, possibly the media_server and the radio interface
> >>> glue)" (plus possibly some kernel activity) are the only things
> >>> looked at when considering if it's safe to sleep or not, all of
> >>> these can (or already do) do 'something' every few seconds, making
> >>> this problem sound significantly smaller than it sounded like
> >>> before.
> >>>
> >>> Android could even keep it's user-space API between the system power
> >>> daemon and the rest of userspace the same if they want to.
> >>>
> >>> over time, additional apps could be considered 'trusted' (or flagged
> >>> that way by the user) and not have to interact with the power daemon
> >>> to keep things alive.
> >>
> >> Hmmm... ?Isn't it the "trusted" (AKA PM-driving) apps that interact with
> >> the power daemon via suspend blockers, rather than the other way around?
> >
> > I was looking at it from a kernel point of view, "trusted" (AKA PM-driving)
> > apps are ones that have permission to grab the wakelock. Any app/daemon that
> > is so trusted can communicate with anything else in userspace as part of
> > making it's decision on whento take the wakelock, but those other
> > applications would not qualify as "trusted" in my eyes.
> >
> >>> as for intramentation, the key tool to use to see why a system isn't
> >>> going to sleep would be powertop, just like on other linux systems.
> >>
> >> Powertop is indeed an extremely valuable tool, but I am not certain
> >> that it really provides the information that the Android guys need.
> >> If I understand Arve's and Brian's posts, here is the scenario that they
> >> are trying to detect:
> >>
> >> o ? ? ? Some PM-driving application has a bug in which it fails to
> >> ? ? ? ?release a wakelock, thus blocking suspend indefinitely.
> >>
> >> o ? ? ? This PM-driving application, otherwise being a good citizen,
> >> ? ? ? ?blocks.
> >>
> >> o ? ? ? There are numerous power-oblivious apps running, consuming
> >> ? ? ? ?significant CPU.
> >>
> >> What the Android developers need to know is that the trusted application
> >> is wrongly holding a wakelock. ?Won't powertop instead tell them about
> >> all the power-oblivious apps?
> >
> > in my proposal (without a wakelock), powertop would tell you what
> > applications are running and setting timers. If we can modify the
> > kernel/suspend decision code to only look at processes in one cgroup when
> > deciding if the system should go to sleep, a similar modification to
> > poewrtop should let you only show stats on the "trusted" applications.
> >
> > If you have a userspace power management daemon that accepts requests from
> > untrusted programs and does something to keep the system from sleeping
> > (either taking a wakelock or setting a 'short' timer), it needs to keep the
> > records of this itself because otherwise all the kernel will see (with
> > either powertop or wakelock reporting) is that the power management daemon
> > is what kept the system from sleeping.
> >
> > David Lang
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at ?http://www.tux.org/lkml/
> >
On Thu, 5 Aug 2010, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 11:13 AM, kevin granade <[email protected]> wrote:
>> IIRC, this was a major point of their (Android's) power management
>> policy. User input of any kind would reset the "display active"
>> timeout, which is the primary thing keeping random untrusted
>> user-facing programs from being suspended while in use. They seemed
>> to consider this to be a special case in their policy, but from the
>> kernel's point of view it is just another suspend blocker being held.
>
> The display being on should not prevent suspend unless the particular
> platform is incapable of suspending while the display is on.
if that is the case, I'll go back to my question about the untrusted
reader app.
what is it that will prevent the system from going to sleep while I am
reading the page?
>> I'm not sure this is the best use case to look at though, because
>> since it is user-facing, the timeout durations are on a different
>> scale than the ones they are really worried about. I think another
>> category of use case that they are worried about is:
>>
>> (in suspend) -> wakeup due to network -> process network activity -> suspend
>>
>> or an example that has been mentioned previously:
>>
>> (in suspend) -> wakeup due to alarm for audio processing -> process
>> batch of audio -> suspend
>>
>> In both of these cases, the display may never power on (phone might
>> beep to indicate txt message or email, audio just keeps playing), so
>> the magnitude of the "timeout" for suspending again should be very
>> small. Specifically, they don't want there to be a timeout at all, so
>> as little time as possible time is spent out of suspend in addition to
>> the time required to handle the event that caused wakeup.
>
> Yeah, we much prefer the wakelock model where the moment the resource
> (system-needing-to-not-be-suspended) is released we return to the
> lowest power state, rather than waiting for a timer to expire (and/or
> burning cycles polling for "can we suspend yet?" when we're definitely
> not ready to suspend).
at the micro level it is definantly better for power, but at the macro
level I don't think it needs to make much difference in the overall
battery life of the device. To borrow a phrase, I think you may be into
premature optimization of power :-)
David Lang
On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:
>> On Thu, Aug 5, 2010 at 10:46 AM, ?<[email protected]> wrote:
>> > On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>> >
>> >> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>> >>>
>> >>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>> >>>>
>> >>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>> >>>>>
>> >>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>> >>
>> >> [ . . . ]
>> >>
>> >>>>>> The music player is an interesting example. ?It would be idle most
>> >>>>>> of the time, given that audio output doesn't consume very much CPU.
>> >>>>>> So you would not want to suspend the system just because there were
>> >>>>>> no runnable processes. ?In contrast, allowing the music player to
>> >>>>>> hold a wake lock lets the system know that it would not be appropriate
>> >>>>>> to suspend.
>> >>>>>>
>> >>>>>> Or am I misunderstanding what you are proposing?
>> >>>>>
>> >>>>> the system would need to be idle for 'long enough' (configurable)
>> >>>>> before deciding to suspend, so as long as 'long enough' is longer
>> >>>>> than the music player is idle this would not be a problem.
>> >>>>
>> >>>> From a user standpoint, having the music player tell the system when
>> >>>> it is OK to suspend (e.g., when the user has paused playback) seems
>> >>>> a lot nicer than having configurable timeouts that need tweaking.
>> >>>
>> >>> every system that I have seen has a configurable "sleep if it's idle
>> >>> for this long" knob. On the iphone (work issue, I didn't want it)
>> >>> that I am currently using it can be configured from 1 min to 5 min.
>> >>>
>> >>> this is the sort of timeout I am talking about.
>> >>>
>> >>> with something in the multi-minute range for the 'do a full suspend'
>> >>> doing a wakeup every few 10s of seconds is perfectly safe.
>> >>
>> >> Ah, I was assuming -much- shorter "do full suspend" timeouts.
>> >>
>> >> My (possibly incorrect) assumption is based on the complaint that led
>> >> to my implementing RCU_FAST_NO_HZ. ?A (non-Android) embedded person was
>> >> quite annoyed (to put it mildly) at the earlier version of RCU because
>> >> it prevented the system from entering the power-saving dyntick-idle mode,
>> >> not for minutes, or even for seconds, but for a handful of -milliseconds-.
>> >> This was my first hint that "energy efficiency" means something completely
>> >> different in embedded systems than it does in the servers that I am
>> >> used to.
>> >>
>> >> But I must defer to the Android guys on this -- who knows, perhaps
>> >> multi-minute delays to enter full-suspend mode are OK for them.
>> >
>> > if the system was looking at all applications I would agree that the timeout
>> > should be much shorter.
>> >
>> > I have a couple devices that are able to have the display usable, even if
>> > the CPU is asleep (the OLPC and the Kindle, two different display
>> > technologies). With these devices I would like to see the suspend happen so
>> > fast that it can suspend between keystrokes.
>> >
>> > however, in the case of Android I think the timeouts have to end up being
>> > _much_ longer. Otherwise you have the problem of loading an untrusted book
>> > reader app on the device and the device suspends while you are reading the
>> > page.
>> >
>> > currently Android works around this by having a wakelock held whenever the
>> > display is on. This seems backwards to me, the display should be on because
>> > the system is not suspended, not the system is prevented from suspending
>> > because the display is on.
>> >
>> > Rather than having the display be on causing a wavelock to be held (with the
>> > code that is controls the display having a timeout for how long it leaves
>> > the display on), I would invert this and have the timeout be based on system
>> > activity, and when it decides the system is not active, turn off the display
>> > (along with other things as it suspends)
>>
>> IIRC, this was a major point of their (Android's) power management
>> policy. ?User input of any kind would reset the "display active"
>> timeout, which is the primary thing keeping random untrusted
>> user-facing programs from being suspended while in use. ?They seemed
>> to consider this to be a special case in their policy, but from the
>> kernel's point of view it is just another suspend blocker being held.
>>
>> I'm not sure this is the best use case to look at though, because
>> since it is user-facing, the timeout durations are on a different
>> scale than the ones they are really worried about. ?I think another
>> category of use case that they are worried about is:
>>
>> (in suspend) -> wakeup due to network -> process network activity -> suspend
>>
>> or an example that has been mentioned previously:
>>
>> (in suspend) -> wakeup due to alarm for audio processing -> process
>> batch of audio -> suspend
>>
>> In both of these cases, the display may never power on (phone might
>> beep to indicate txt message or email, audio just keeps playing), so
>> the magnitude of the "timeout" for suspending again should be very
>> small. ?Specifically, they don't want there to be a timeout at all, so
>> as little time as possible time is spent out of suspend in addition to
>> the time required to handle the event that caused wakeup.
>
> It would be good to get some sort of range for the "timeout". ?In the
> audio-output case, my understanding that the spacing between bursts of
> audio-processing activity is measured in some hundreds of milliseconds,
> in which case one would want the delays until suspend to be on the
> millisecond scale. ?But does Android really suspend between bursts of
> audio processing while playing music? ?Very cool if so! ?;-)
Oops, yea that's actually a really bad example, that's probably
something that would be handled by low-power states. I think the
incoming text message example is a good one though. There seemed to
be a focus on user-interaction scale time scales, and I wanted to
point out that there are also very short duration time scales to
consider as well.
*back to lurking*
Kevin
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Thanx, Paul
>
>> >>>>>>> if the backlight being on holds the wakelock, it would seem that
>> >>>>>>> almost every other use of the wakelock could (and probably should)
>> >>>>>>> be replaced by something that tickles the display to stay on longer.
>> >>>>>>
>> >>>>>> The problem with this approach is that the display consumes quite a
>> >>>>>> bit of power, so you don't want to leave it on unnecessarily. ?So if
>> >>>>>> the system is doing something (for example, playing music) that does
>> >>>>>> not require the display, you really want the display to be off.
>> >>>>>
>> >>>>> what percentage (and types) of apps are really useful with the
>> >>>>> display off. I think that there are relativly few apps that you
>> >>>>> really want to keep running if the display is off.
>> >>>>
>> >>>> The length of time those apps are running is the governing factor
>> >>>> for battery life, and not the number of such apps, right?
>> >>>
>> >>> correct, but the number of such apps indicates the scope of the problem.
>> >>
>> >> The number of such apps certainly indicates the amount of effort required
>> >> to modify them, if required. ?Is that what you are getting at?
>> >
>> > yes.
>> >
>> >>>> From another e-mail tonight it sounds like almost everything
>> >>>> already talks
>> >>>
>> >>> to a userspace daemon, so if "(the power management service in the
>> >>> system_server, possibly the media_server and the radio interface
>> >>> glue)" (plus possibly some kernel activity) are the only things
>> >>> looked at when considering if it's safe to sleep or not, all of
>> >>> these can (or already do) do 'something' every few seconds, making
>> >>> this problem sound significantly smaller than it sounded like
>> >>> before.
>> >>>
>> >>> Android could even keep it's user-space API between the system power
>> >>> daemon and the rest of userspace the same if they want to.
>> >>>
>> >>> over time, additional apps could be considered 'trusted' (or flagged
>> >>> that way by the user) and not have to interact with the power daemon
>> >>> to keep things alive.
>> >>
>> >> Hmmm... ?Isn't it the "trusted" (AKA PM-driving) apps that interact with
>> >> the power daemon via suspend blockers, rather than the other way around?
>> >
>> > I was looking at it from a kernel point of view, "trusted" (AKA PM-driving)
>> > apps are ones that have permission to grab the wakelock. Any app/daemon that
>> > is so trusted can communicate with anything else in userspace as part of
>> > making it's decision on whento take the wakelock, but those other
>> > applications would not qualify as "trusted" in my eyes.
>> >
>> >>> as for intramentation, the key tool to use to see why a system isn't
>> >>> going to sleep would be powertop, just like on other linux systems.
>> >>
>> >> Powertop is indeed an extremely valuable tool, but I am not certain
>> >> that it really provides the information that the Android guys need.
>> >> If I understand Arve's and Brian's posts, here is the scenario that they
>> >> are trying to detect:
>> >>
>> >> o ? ? ? Some PM-driving application has a bug in which it fails to
>> >> ? ? ? ?release a wakelock, thus blocking suspend indefinitely.
>> >>
>> >> o ? ? ? This PM-driving application, otherwise being a good citizen,
>> >> ? ? ? ?blocks.
>> >>
>> >> o ? ? ? There are numerous power-oblivious apps running, consuming
>> >> ? ? ? ?significant CPU.
>> >>
>> >> What the Android developers need to know is that the trusted application
>> >> is wrongly holding a wakelock. ?Won't powertop instead tell them about
>> >> all the power-oblivious apps?
>> >
>> > in my proposal (without a wakelock), powertop would tell you what
>> > applications are running and setting timers. If we can modify the
>> > kernel/suspend decision code to only look at processes in one cgroup when
>> > deciding if the system should go to sleep, a similar modification to
>> > poewrtop should let you only show stats on the "trusted" applications.
>> >
>> > If you have a userspace power management daemon that accepts requests from
>> > untrusted programs and does something to keep the system from sleeping
>> > (either taking a wakelock or setting a 'short' timer), it needs to keep the
>> > records of this itself because otherwise all the kernel will see (with
>> > either powertop or wakelock reporting) is that the power management daemon
>> > is what kept the system from sleeping.
>> >
>> > David Lang
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to [email protected]
>> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at ?http://www.tux.org/lkml/
>> >
>
2010/8/5 Rafael J. Wysocki <[email protected]>:
> On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
>> 2010/8/4 Rafael J. Wysocki <[email protected]>:
>> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
>> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
>> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>> >> >> > No! And that's precisely the issue. Android's existing behaviour could
>> >> >> > be entirely implemented in the form of binary that manually triggers
>> >> >> > suspend when (a) the screen is off and (b) no userspace applications
>> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
>> >> >> > event race. Imagine the following:
>> >> >> >
>> >> >> > 1) The policy timeout is about to expire. No applications are holding
>> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
>> >> >> > 2) A network packet arrives indicating an incoming SIP call
>> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
>> >> >> > suspending while the call is in progress
>> >> >> >
>> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
>> >> >> > because the voip app is an otherwise untrusted application that you've
>> >> >> > just told the scheduler to ignore.
>> >> >>
>> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
>> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
>> >> >
>> >> > Yes, I think that solves the problem. The only question then is whether
>> >>
>> >> How? By passing a timeout to pm_wakeup_event when the network driver
>> >> gets the packet or by passing 0. If you pass a timeout it is the same
>> >> as using a wakelock with a timeout and should work (assuming the
>> >> timeout you picked is long enough). If you don't pass a timeout it
>> >> does not work, since the packet may not be visible to user-space yet.
>> >
>> > Alternatively, pm_stay_awake() / pm_relax() can be used.
>> >
>>
>> Which makes the driver and/or network stack changes identical to using
>> wakelocks, right?
>
> Please refer to the Matthew's response.
>
>> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
>> >> > to the implementation. In other words, is there a reason we're still
>> >>
>> >> I have seen no proposed way to use cgroups that will work. If you
>> >> leave some processes running while other processes are frozen you run
>> >> into problems when a frozen process holds a resource that a running
>> >> process needs.
>> >>
>> >>
>> >> > having this conversation? :) It'd be good to have some feedback from
>> >> > Google as to whether this satisfies their functional requirements.
>> >> >
>> >>
>> >> That is "this"? The merged code? If so, no it does not satisfy our
>> >> requirements. The in kernel api, while offering similar functionality
>> >> to the wakelock interface, does not use any handles which makes it
>> >> impossible to get reasonable stats (You don't know which pm_stay_awake
>> >> request pm_relax is reverting).
>> >
>> > Why is that a problem (out of curiosity)?
>> >
>>
>> Not having stats or not knowing what pm_relax is undoing? We need
>> stats to be able to debug the system.
>
> You have the stats in struct device and they are available via sysfs.
> I suppose they are insufficient, but I'd like to know why exactly.
>
Our wakelock stats currently have
(name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
and last_change. Not all of these are equally important (total_time is
most important followed by active_since), but you only have count.
Also as discussed before, many wakelocks/suspendblockers are not
associated with a struct device.
>> If the system does not suspend
>> at all or is awake for too long, the wakelock stats tells us which
>> component is at fault. Since pm_stay_awake and pm_relax does not
>> operate on a handle, you cannot determine how long it prevented
>> suspend for.
>
> Well, if you need that, you can add a counter of "completed events" into
We need more than that (see above).
> struct dev_pm_info and a function similar to pm_relax() that
> will update that counter. ?I don't think anyone will object to that change.
>
What about adding a handle that is passed to all three functions?
>> >> The proposed in user-space interface
>> >> of calling into every process that receives wakeup events before every
>> >> suspend call
>> >
>> > Well, ?you don't really need to do that.
>> >
>>
>> Only if the driver blocks suspend until user-space has read the event.
>> This means that for android to work we need to block suspend when
>> input events are not processed, but a system using your scheme needs a
>> pm_wakeup_event call when the input event is queued. How to you switch
>> between them? Do we add separate ioctls in the input device to enable
>> each scheme? If someone has a single threaded user space power manager
>> that also reads input event it will deadlock if you block suspend
>> until it reads the input events since you block when reading the wake
>> count.
>
> Well, until someone actually tries to implement a power manager in user space
> it's a bit vague.
>
Not having clear rules for what the drivers should do is a problem.
The comments in your code seem to advocate using timeouts instead of
overlapping pm_stay_awake/pm_relax sections. I find this
recommendation strange given all the opposition to
wakelock/suspendblocker timeouts. But more importantly, calling
pm_wakeup_event with a timeout of 0 is incompatible with the android
user space code, and I would prefer that the kernel interfaces would
encourage drivers to block suspend until user space has consumed the
event, which works for the android user space, instead of just long
enough to work with a hypothetical user space power manager.
--
Arve Hj?nnev?g
On Thu, 5 Aug 2010, kevin granade wrote:
> On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney
> <[email protected]> wrote:
>> On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:
>>> On Thu, Aug 5, 2010 at 10:46 AM, ?<[email protected]> wrote:
>>>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>>
>>>>> [ . . . ]
>>>>>
>>>>>
>>>>> My (possibly incorrect) assumption is based on the complaint that led
>>>>> to my implementing RCU_FAST_NO_HZ. ?A (non-Android) embedded person was
>>>>> quite annoyed (to put it mildly) at the earlier version of RCU because
>>>>> it prevented the system from entering the power-saving dyntick-idle mode,
>>>>> not for minutes, or even for seconds, but for a handful of -milliseconds-.
>>>>> This was my first hint that "energy efficiency" means something completely
>>>>> different in embedded systems than it does in the servers that I am
>>>>> used to.
>>>>>
>>>>> But I must defer to the Android guys on this -- who knows, perhaps
>>>>> multi-minute delays to enter full-suspend mode are OK for them.
>>>>
>>>> if the system was looking at all applications I would agree that the timeout
>>>> should be much shorter.
>>>>
>>>> I have a couple devices that are able to have the display usable, even if
>>>> the CPU is asleep (the OLPC and the Kindle, two different display
>>>> technologies). With these devices I would like to see the suspend happen so
>>>> fast that it can suspend between keystrokes.
>>>>
>>>> however, in the case of Android I think the timeouts have to end up being
>>>> _much_ longer. Otherwise you have the problem of loading an untrusted book
>>>> reader app on the device and the device suspends while you are reading the
>>>> page.
>>>>
>>>> currently Android works around this by having a wakelock held whenever the
>>>> display is on. This seems backwards to me, the display should be on because
>>>> the system is not suspended, not the system is prevented from suspending
>>>> because the display is on.
>>>>
>>>> Rather than having the display be on causing a wavelock to be held (with the
>>>> code that is controls the display having a timeout for how long it leaves
>>>> the display on), I would invert this and have the timeout be based on system
>>>> activity, and when it decides the system is not active, turn off the display
>>>> (along with other things as it suspends)
>>>
>>> IIRC, this was a major point of their (Android's) power management
>>> policy. ?User input of any kind would reset the "display active"
>>> timeout, which is the primary thing keeping random untrusted
>>> user-facing programs from being suspended while in use. ?They seemed
>>> to consider this to be a special case in their policy, but from the
>>> kernel's point of view it is just another suspend blocker being held.
>>>
>>> I'm not sure this is the best use case to look at though, because
>>> since it is user-facing, the timeout durations are on a different
>>> scale than the ones they are really worried about. ?I think another
>>> category of use case that they are worried about is:
>>>
>>> (in suspend) -> wakeup due to network -> process network activity -> suspend
>>>
>>> or an example that has been mentioned previously:
>>>
>>> (in suspend) -> wakeup due to alarm for audio processing -> process
>>> batch of audio -> suspend
>>>
>>> In both of these cases, the display may never power on (phone might
>>> beep to indicate txt message or email, audio just keeps playing), so
>>> the magnitude of the "timeout" for suspending again should be very
>>> small. ?Specifically, they don't want there to be a timeout at all, so
>>> as little time as possible time is spent out of suspend in addition to
>>> the time required to handle the event that caused wakeup.
>>
>> It would be good to get some sort of range for the "timeout". ?In the
>> audio-output case, my understanding that the spacing between bursts of
>> audio-processing activity is measured in some hundreds of milliseconds,
>> in which case one would want the delays until suspend to be on the
>> millisecond scale. ?But does Android really suspend between bursts of
>> audio processing while playing music? ?Very cool if so! ?;-)
>
> Oops, yea that's actually a really bad example, that's probably
> something that would be handled by low-power states. I think the
> incoming text message example is a good one though. There seemed to
> be a focus on user-interaction scale time scales, and I wanted to
> point out that there are also very short duration time scales to
> consider as well.
good point, but I do think the short time scales are less common than
people think.
I'd love to get good examples of them
on my iphone when a text message arrives the phone displays an alert for
user-interaction times (it even lights the display to show who the message
is from, and optionally a preview of the message)
so what would wake a phone up from suspend where the phone should go back
to sleep in under a second?
David Lang
On Thu, Aug 5, 2010 at 3:09 PM, <[email protected]> wrote:
>> Oops, yea that's actually a really bad example, that's probably
>> something that would be handled by low-power states. I think the
>> incoming text message example is a good one though. There seemed to
>> be a focus on user-interaction scale time scales, and I wanted to
>> point out that there are also very short duration time scales to
>> consider as well.
>
> good point, but I do think the short time scales are less common than people
> think.
>
> I'd love to get good examples of them
>
> on my iphone when a text message arrives the phone displays an alert for
> user-interaction times (it even lights the display to show who the message
> is from, and optionally a preview of the message)
>
> so what would wake a phone up from suspend where the phone should go back to
> sleep in under a second?
Here are some real-world examples from shipped android devices:
- battery gauging happens every 10 minutes, need to wake long enough
to chatter with the 1w interface and make sure the battery is not
exploding
- always on mail/im/calendar/etc sync often has network events that
happen every 5-10 minutes which cause devices to briefly wake up and
return to sleep
- gps tracker app might wake every couple minutes or every n gps
events to log location
- low power audio subsystems can wake you up every 1-4 seconds (pcm)
or 1-4 minutes (mp3) to fetch more data
Brian
On Thu, Aug 05, 2010 at 03:16:51PM -0700, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 3:09 PM, <[email protected]> wrote:
> >> Oops, yea that's actually a really bad example, that's probably
> >> something that would be handled by low-power states. ?I think the
> >> incoming text message example is a good one though. ?There seemed to
> >> be a focus on user-interaction scale time scales, and I wanted to
> >> point out that there are also very short duration time scales to
> >> consider as well.
> >
> > good point, but I do think the short time scales are less common than people
> > think.
> >
> > I'd love to get good examples of them
> >
> > on my iphone when a text message arrives the phone displays an alert for
> > user-interaction times (it even lights the display to show who the message
> > is from, and optionally a preview of the message)
> >
> > so what would wake a phone up from suspend where the phone should go back to
> > sleep in under a second?
>
> Here are some real-world examples from shipped android devices:
> - battery gauging happens every 10 minutes, need to wake long enough
> to chatter with the 1w interface and make sure the battery is not
> exploding
> - always on mail/im/calendar/etc sync often has network events that
> happen every 5-10 minutes which cause devices to briefly wake up and
> return to sleep
> - gps tracker app might wake every couple minutes or every n gps
> events to log location
> - low power audio subsystems can wake you up every 1-4 seconds (pcm)
> or 1-4 minutes (mp3) to fetch more data
Interesting!
So for an mp3 playback, does an Android suspend between data fetches?
Thanx, Paul
On Thu, Aug 05, 2010 at 03:51:35PM -0500, kevin granade wrote:
> On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:
> >> On Thu, Aug 5, 2010 at 10:46 AM, ?<[email protected]> wrote:
> >> > On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> >> >
> >> >> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> >> >>>
> >> >>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >> >>>>
> >> >>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >> >>>>>
> >> >>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >> >>
> >> >> [ . . . ]
> >> >>
> >> >>>>>> The music player is an interesting example. ?It would be idle most
> >> >>>>>> of the time, given that audio output doesn't consume very much CPU.
> >> >>>>>> So you would not want to suspend the system just because there were
> >> >>>>>> no runnable processes. ?In contrast, allowing the music player to
> >> >>>>>> hold a wake lock lets the system know that it would not be appropriate
> >> >>>>>> to suspend.
> >> >>>>>>
> >> >>>>>> Or am I misunderstanding what you are proposing?
> >> >>>>>
> >> >>>>> the system would need to be idle for 'long enough' (configurable)
> >> >>>>> before deciding to suspend, so as long as 'long enough' is longer
> >> >>>>> than the music player is idle this would not be a problem.
> >> >>>>
> >> >>>> From a user standpoint, having the music player tell the system when
> >> >>>> it is OK to suspend (e.g., when the user has paused playback) seems
> >> >>>> a lot nicer than having configurable timeouts that need tweaking.
> >> >>>
> >> >>> every system that I have seen has a configurable "sleep if it's idle
> >> >>> for this long" knob. On the iphone (work issue, I didn't want it)
> >> >>> that I am currently using it can be configured from 1 min to 5 min.
> >> >>>
> >> >>> this is the sort of timeout I am talking about.
> >> >>>
> >> >>> with something in the multi-minute range for the 'do a full suspend'
> >> >>> doing a wakeup every few 10s of seconds is perfectly safe.
> >> >>
> >> >> Ah, I was assuming -much- shorter "do full suspend" timeouts.
> >> >>
> >> >> My (possibly incorrect) assumption is based on the complaint that led
> >> >> to my implementing RCU_FAST_NO_HZ. ?A (non-Android) embedded person was
> >> >> quite annoyed (to put it mildly) at the earlier version of RCU because
> >> >> it prevented the system from entering the power-saving dyntick-idle mode,
> >> >> not for minutes, or even for seconds, but for a handful of -milliseconds-.
> >> >> This was my first hint that "energy efficiency" means something completely
> >> >> different in embedded systems than it does in the servers that I am
> >> >> used to.
> >> >>
> >> >> But I must defer to the Android guys on this -- who knows, perhaps
> >> >> multi-minute delays to enter full-suspend mode are OK for them.
> >> >
> >> > if the system was looking at all applications I would agree that the timeout
> >> > should be much shorter.
> >> >
> >> > I have a couple devices that are able to have the display usable, even if
> >> > the CPU is asleep (the OLPC and the Kindle, two different display
> >> > technologies). With these devices I would like to see the suspend happen so
> >> > fast that it can suspend between keystrokes.
> >> >
> >> > however, in the case of Android I think the timeouts have to end up being
> >> > _much_ longer. Otherwise you have the problem of loading an untrusted book
> >> > reader app on the device and the device suspends while you are reading the
> >> > page.
> >> >
> >> > currently Android works around this by having a wakelock held whenever the
> >> > display is on. This seems backwards to me, the display should be on because
> >> > the system is not suspended, not the system is prevented from suspending
> >> > because the display is on.
> >> >
> >> > Rather than having the display be on causing a wavelock to be held (with the
> >> > code that is controls the display having a timeout for how long it leaves
> >> > the display on), I would invert this and have the timeout be based on system
> >> > activity, and when it decides the system is not active, turn off the display
> >> > (along with other things as it suspends)
> >>
> >> IIRC, this was a major point of their (Android's) power management
> >> policy. ?User input of any kind would reset the "display active"
> >> timeout, which is the primary thing keeping random untrusted
> >> user-facing programs from being suspended while in use. ?They seemed
> >> to consider this to be a special case in their policy, but from the
> >> kernel's point of view it is just another suspend blocker being held.
> >>
> >> I'm not sure this is the best use case to look at though, because
> >> since it is user-facing, the timeout durations are on a different
> >> scale than the ones they are really worried about. ?I think another
> >> category of use case that they are worried about is:
> >>
> >> (in suspend) -> wakeup due to network -> process network activity -> suspend
> >>
> >> or an example that has been mentioned previously:
> >>
> >> (in suspend) -> wakeup due to alarm for audio processing -> process
> >> batch of audio -> suspend
> >>
> >> In both of these cases, the display may never power on (phone might
> >> beep to indicate txt message or email, audio just keeps playing), so
> >> the magnitude of the "timeout" for suspending again should be very
> >> small. ?Specifically, they don't want there to be a timeout at all, so
> >> as little time as possible time is spent out of suspend in addition to
> >> the time required to handle the event that caused wakeup.
> >
> > It would be good to get some sort of range for the "timeout". ?In the
> > audio-output case, my understanding that the spacing between bursts of
> > audio-processing activity is measured in some hundreds of milliseconds,
> > in which case one would want the delays until suspend to be on the
> > millisecond scale. ?But does Android really suspend between bursts of
> > audio processing while playing music? ?Very cool if so! ?;-)
>
> Oops, yea that's actually a really bad example, that's probably
> something that would be handled by low-power states. I think the
> incoming text message example is a good one though. There seemed to
> be a focus on user-interaction scale time scales, and I wanted to
> point out that there are also very short duration time scales to
> consider as well.
>
> *back to lurking*
I really don't know the answer myself, so I was really asking the
question rather than trying to catch you out.
Thanx, Paul
> Kevin
>
> >
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Thanx, Paul
> >
> >> >>>>>>> if the backlight being on holds the wakelock, it would seem that
> >> >>>>>>> almost every other use of the wakelock could (and probably should)
> >> >>>>>>> be replaced by something that tickles the display to stay on longer.
> >> >>>>>>
> >> >>>>>> The problem with this approach is that the display consumes quite a
> >> >>>>>> bit of power, so you don't want to leave it on unnecessarily. ?So if
> >> >>>>>> the system is doing something (for example, playing music) that does
> >> >>>>>> not require the display, you really want the display to be off.
> >> >>>>>
> >> >>>>> what percentage (and types) of apps are really useful with the
> >> >>>>> display off. I think that there are relativly few apps that you
> >> >>>>> really want to keep running if the display is off.
> >> >>>>
> >> >>>> The length of time those apps are running is the governing factor
> >> >>>> for battery life, and not the number of such apps, right?
> >> >>>
> >> >>> correct, but the number of such apps indicates the scope of the problem.
> >> >>
> >> >> The number of such apps certainly indicates the amount of effort required
> >> >> to modify them, if required. ?Is that what you are getting at?
> >> >
> >> > yes.
> >> >
> >> >>>> From another e-mail tonight it sounds like almost everything
> >> >>>> already talks
> >> >>>
> >> >>> to a userspace daemon, so if "(the power management service in the
> >> >>> system_server, possibly the media_server and the radio interface
> >> >>> glue)" (plus possibly some kernel activity) are the only things
> >> >>> looked at when considering if it's safe to sleep or not, all of
> >> >>> these can (or already do) do 'something' every few seconds, making
> >> >>> this problem sound significantly smaller than it sounded like
> >> >>> before.
> >> >>>
> >> >>> Android could even keep it's user-space API between the system power
> >> >>> daemon and the rest of userspace the same if they want to.
> >> >>>
> >> >>> over time, additional apps could be considered 'trusted' (or flagged
> >> >>> that way by the user) and not have to interact with the power daemon
> >> >>> to keep things alive.
> >> >>
> >> >> Hmmm... ?Isn't it the "trusted" (AKA PM-driving) apps that interact with
> >> >> the power daemon via suspend blockers, rather than the other way around?
> >> >
> >> > I was looking at it from a kernel point of view, "trusted" (AKA PM-driving)
> >> > apps are ones that have permission to grab the wakelock. Any app/daemon that
> >> > is so trusted can communicate with anything else in userspace as part of
> >> > making it's decision on whento take the wakelock, but those other
> >> > applications would not qualify as "trusted" in my eyes.
> >> >
> >> >>> as for intramentation, the key tool to use to see why a system isn't
> >> >>> going to sleep would be powertop, just like on other linux systems.
> >> >>
> >> >> Powertop is indeed an extremely valuable tool, but I am not certain
> >> >> that it really provides the information that the Android guys need.
> >> >> If I understand Arve's and Brian's posts, here is the scenario that they
> >> >> are trying to detect:
> >> >>
> >> >> o ? ? ? Some PM-driving application has a bug in which it fails to
> >> >> ? ? ? ?release a wakelock, thus blocking suspend indefinitely.
> >> >>
> >> >> o ? ? ? This PM-driving application, otherwise being a good citizen,
> >> >> ? ? ? ?blocks.
> >> >>
> >> >> o ? ? ? There are numerous power-oblivious apps running, consuming
> >> >> ? ? ? ?significant CPU.
> >> >>
> >> >> What the Android developers need to know is that the trusted application
> >> >> is wrongly holding a wakelock. ?Won't powertop instead tell them about
> >> >> all the power-oblivious apps?
> >> >
> >> > in my proposal (without a wakelock), powertop would tell you what
> >> > applications are running and setting timers. If we can modify the
> >> > kernel/suspend decision code to only look at processes in one cgroup when
> >> > deciding if the system should go to sleep, a similar modification to
> >> > poewrtop should let you only show stats on the "trusted" applications.
> >> >
> >> > If you have a userspace power management daemon that accepts requests from
> >> > untrusted programs and does something to keep the system from sleeping
> >> > (either taking a wakelock or setting a 'short' timer), it needs to keep the
> >> > records of this itself because otherwise all the kernel will see (with
> >> > either powertop or wakelock reporting) is that the power management daemon
> >> > is what kept the system from sleeping.
> >> >
> >> > David Lang
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> > the body of a message to [email protected]
> >> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> >> > Please read the FAQ at ?http://www.tux.org/lkml/
> >> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, Aug 05, 2010 at 01:26:18PM -0700, [email protected] wrote:
> On Thu, 5 Aug 2010, kevin granade wrote:
>
> >On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
> >>On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> >>
> >>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> >>>>
> >>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>>>
> >>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >>>>>>
> >>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>
> >>>[ . . . ]
> >>>
> >>however, in the case of Android I think the timeouts have to end up being
> >>_much_ longer. Otherwise you have the problem of loading an untrusted book
> >>reader app on the device and the device suspends while you are reading the
> >>page.
> >>
> >>currently Android works around this by having a wakelock held whenever the
> >>display is on. This seems backwards to me, the display should be on because
> >>the system is not suspended, not the system is prevented from suspending
> >>because the display is on.
> >>
> >>Rather than having the display be on causing a wavelock to be held (with the
> >>code that is controls the display having a timeout for how long it leaves
> >>the display on), I would invert this and have the timeout be based on system
> >>activity, and when it decides the system is not active, turn off the display
> >>(along with other things as it suspends)
> >
> >IIRC, this was a major point of their (Android's) power management
> >policy. User input of any kind would reset the "display active"
> >timeout, which is the primary thing keeping random untrusted
> >user-facing programs from being suspended while in use. They seemed
> >to consider this to be a special case in their policy, but from the
> >kernel's point of view it is just another suspend blocker being held.
> >
> >I'm not sure this is the best use case to look at though, because
> >since it is user-facing, the timeout durations are on a different
> >scale than the ones they are really worried about. I think another
> >category of use case that they are worried about is:
> >
> >(in suspend) -> wakeup due to network -> process network activity -> suspend
> >
> >or an example that has been mentioned previously:
> >
> >(in suspend) -> wakeup due to alarm for audio processing -> process
> >batch of audio -> suspend
>
> when you suspend the audio will shut off, so it's sleep ->wake ->
> sleep, not suspend
>
> >In both of these cases, the display may never power on (phone might
> >beep to indicate txt message or email, audio just keeps playing), so
> >the magnitude of the "timeout" for suspending again should be very
> >small. Specifically, they don't want there to be a timeout at all, so
> >as little time as possible time is spent out of suspend in addition to
> >the time required to handle the event that caused wakeup.
>
> it really depnds on the frequency of the wakeups.
>
> if you get a network packet once every 5 min and need to wake to
> process it, staying awake for 20 seconds after finishing procesing
> is FAR more significant than if you get a network packet once every
> hour. It's not just the factor of 20 that simple math would indicate
> because the time in suspend eats power as well.
>
> I don't know real numbers, so these are made up for this example
>
> if suspend (with the cell live to receive packets) is 10ma average
> current and full power is 500ma average current
>
> packets every 5 min with .1 sec wake time will eat ~13maH per hour
>
> packets every 5 min with 10 second wake time will eat ~37maH per hour
>
> packets every hour with .1 sec wake time will eat ~10maH per hour
>
> packets every hour with 10 sec wake time will eat ~11maH per hour
>
> so if you have frequent wakeups, staying awake 100 times as long
> will cut your battery life to 1/3 what it was before.
>
> if your wakeups are rare, it's about a 10% hit to stay awake 100
> times as long.
>
> there is a lot of room for tuning the timeouts here.
Especially given different scenarios, for example, audio playback
when the device is in airplane mode. ;-)
Thanx, Paul
On Thu, Aug 05, 2010 at 06:37:15AM -0700, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 6:18 AM, <[email protected]> wrote:
> > On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >
> >> Continuing to rush in where angels fear to tread...
> >
> > here here :-)
> >
> >> o ? ? ? "PM-driving 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,
> >> ? ? ? ?PM-driving applications seem to be those that have permission
> >> ? ? ? ?to exert some control over the system's sleep state.
> >>
> >> ? ? ? ?Note that an application might be power-oblivious on one Android
> >> ? ? ? ?device and PM-driving on another, depending on whether the user
> >> ? ? ? ?allows that application to acquire suspend blockers. ?The
> >> ? ? ? ?classification might even change over time. ?For example, a
> >> ? ? ? ?user might give an application PM-driving status initially,
> >> ? ? ? ?but change his or her mind after some experience with that
> >> ? ? ? ?application.
> >
> > One thing that I think it's important to document here is theinformation
> > that Brian provided in response to your question about how many (or actually
> > how few) applications fall into this catefory
>
> I think I need to clarify here. When I say "app" in the context of
> Android, I mean "an application running under the Android app model --
> sandboxed under a per-app or app-group uid", not "a process". The
> vast majority of processes on an Android device are "apps" in this
> sense, but some (usually low level services or daemons) are not. Also
> I use "wakelock" as a place holder for "suspend blocker" or whatever
> exact API we're trying to hash out here, because it's shorter and I'm
> lazy.
>
> Any app may obtain a wakelock through the standard Android APIs,
> provided it has permission to do so. In the current implementation,
> apps obtain wakelocks via making a binder RPC call to the power
> manager service which tracks high level wakelocks (for apps!) and
> backs them by a single kernel wakelock. Access control is at the RPC
> level. This implementation could be changed to have the app API
> simply open /dev/suspendblock or whatnot, with access control enforced
> by unix permissions (the framework would arrange for apps with the
> android "can block sleep" permission to be in a unix group that has
> access to the device).
>
> For native services (native daemons that run "underneath" the android
> app framework -- for example the media service, the radio interface,
> etc), the kernel interface is used directly (ok, usually via a very
> thin C convenience wrapper).
Thank you for the added detail on Android user-space operation!!!
Thanx, Paul
> Brian
>
>
> > Quote:
> >
> >> I should have asked this earlier... ?What exactly are the apps'
> >> compatibility constraints? ?Source-level APIs? ?Byte-code class-library
> >> invocations? ?C/C++ dynamic linking? ?C/C++ static linking (in other
> >> words, syscall)?
> >
> > For Java/Dalvik apps, the wakelock API is pertty high level -- it
> > talks to a service via RPC (Binder) that actually interacts with the
> > kernel. ?Changing the basic kernel<->userspace interface (within
> > reason) is not unthinkable. ?For example, Arve's suspend_blocker patch
> > provides a device interface rather than the proc interface the older
> > wakelock patches use. ?We'd have to make some userspace changes to
> > support that but they're pretty low level and minor.
> >
> > In the current model, only a few processes need to specifically
> > interact with the kernel (the power management service in the
> > system_server, possibly the media_server and the radio interface
> > glue). ?A model where every process needs to have a bunch of
> > instrumentation is not very desirable from our point of view. ?We
> > definitely do need reasonable statistics in order to enable debugging
> > and to enable reporting to endusers (through the Battery Usage UI)
> > what's keeping the device awake.
> >
> > Brian
> >
> >
On Friday, August 06, 2010, Arve Hj?nnev?g wrote:
> 2010/8/5 Rafael J. Wysocki <[email protected]>:
> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> 2010/8/4 Rafael J. Wysocki <[email protected]>:
> >> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> >> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >> >> >> > No! And that's precisely the issue. Android's existing behaviour could
> >> >> >> > be entirely implemented in the form of binary that manually triggers
> >> >> >> > suspend when (a) the screen is off and (b) no userspace applications
> >> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
> >> >> >> > event race. Imagine the following:
> >> >> >> >
> >> >> >> > 1) The policy timeout is about to expire. No applications are holding
> >> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
> >> >> >> > 2) A network packet arrives indicating an incoming SIP call
> >> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
> >> >> >> > suspending while the call is in progress
> >> >> >> >
> >> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> >> >> >> > because the voip app is an otherwise untrusted application that you've
> >> >> >> > just told the scheduler to ignore.
> >> >> >>
> >> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> >> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
> >> >> >
> >> >> > Yes, I think that solves the problem. The only question then is whether
> >> >>
> >> >> How? By passing a timeout to pm_wakeup_event when the network driver
> >> >> gets the packet or by passing 0. If you pass a timeout it is the same
> >> >> as using a wakelock with a timeout and should work (assuming the
> >> >> timeout you picked is long enough). If you don't pass a timeout it
> >> >> does not work, since the packet may not be visible to user-space yet.
> >> >
> >> > Alternatively, pm_stay_awake() / pm_relax() can be used.
> >> >
> >>
> >> Which makes the driver and/or network stack changes identical to using
> >> wakelocks, right?
> >
> > Please refer to the Matthew's response.
> >
> >> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
> >> >> > to the implementation. In other words, is there a reason we're still
> >> >>
> >> >> I have seen no proposed way to use cgroups that will work. If you
> >> >> leave some processes running while other processes are frozen you run
> >> >> into problems when a frozen process holds a resource that a running
> >> >> process needs.
> >> >>
> >> >>
> >> >> > having this conversation? :) It'd be good to have some feedback from
> >> >> > Google as to whether this satisfies their functional requirements.
> >> >> >
> >> >>
> >> >> That is "this"? The merged code? If so, no it does not satisfy our
> >> >> requirements. The in kernel api, while offering similar functionality
> >> >> to the wakelock interface, does not use any handles which makes it
> >> >> impossible to get reasonable stats (You don't know which pm_stay_awake
> >> >> request pm_relax is reverting).
> >> >
> >> > Why is that a problem (out of curiosity)?
> >> >
> >>
> >> Not having stats or not knowing what pm_relax is undoing? We need
> >> stats to be able to debug the system.
> >
> > You have the stats in struct device and they are available via sysfs.
> > I suppose they are insufficient, but I'd like to know why exactly.
> >
>
> Our wakelock stats currently have
> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
> and last_change. Not all of these are equally important (total_time is
> most important followed by active_since), but you only have count.
> Also as discussed before, many wakelocks/suspendblockers are not
> associated with a struct device.
OK
How much of that is used in practice and what for exactly?
Do you _really_ have to debug the wakelocks in drivers that much?
> >> If the system does not suspend
> >> at all or is awake for too long, the wakelock stats tells us which
> >> component is at fault. Since pm_stay_awake and pm_relax does not
> >> operate on a handle, you cannot determine how long it prevented
> >> suspend for.
> >
> > Well, if you need that, you can add a counter of "completed events" into
>
> We need more than that (see above).
>
> > struct dev_pm_info and a function similar to pm_relax() that
> > will update that counter. I don't think anyone will object to that change.
> >
>
> What about adding a handle that is passed to all three functions?
I don't think that will fly at this point.
> >> >> The proposed in user-space interface
> >> >> of calling into every process that receives wakeup events before every
> >> >> suspend call
> >> >
> >> > Well, you don't really need to do that.
> >> >
> >>
> >> Only if the driver blocks suspend until user-space has read the event.
> >> This means that for android to work we need to block suspend when
> >> input events are not processed, but a system using your scheme needs a
> >> pm_wakeup_event call when the input event is queued. How to you switch
> >> between them? Do we add separate ioctls in the input device to enable
> >> each scheme? If someone has a single threaded user space power manager
> >> that also reads input event it will deadlock if you block suspend
> >> until it reads the input events since you block when reading the wake
> >> count.
> >
> > Well, until someone actually tries to implement a power manager in user space
> > it's a bit vague.
> >
>
> Not having clear rules for what the drivers should do is a problem.
> The comments in your code seem to advocate using timeouts instead of
> overlapping pm_stay_awake/pm_relax sections. I find this
> recommendation strange given all the opposition to
> wakelock/suspendblocker timeouts.
There's no recommendation either way.
> But more importantly, calling
> pm_wakeup_event with a timeout of 0 is incompatible with the android
> user space code,
Which I don't find really relevant, sorry.
> and I would prefer that the kernel interfaces would
> encourage drivers to block suspend until user space has consumed the
> event, which works for the android user space, instead of just long
> enough to work with a hypothetical user space power manager.
Well, that are your personal preferences, which I respect. I also have some
personal preferences that are not necessarily followed by the kernel code.
Thanks,
Rafael
On Thu, Aug 5, 2010 at 4:03 PM, Paul E. McKenney
<[email protected]> wrote:
>> > so what would wake a phone up from suspend where the phone should go back to
>> > sleep in under a second?
>>
>> Here are some real-world examples from shipped android devices:
>> - battery gauging happens every 10 minutes, need to wake long enough
>> to chatter with the 1w interface and make sure the battery is not
>> exploding
>> - always on mail/im/calendar/etc sync often has network events that
>> happen every 5-10 minutes which cause devices to briefly wake up and
>> return to sleep
>> - gps tracker app might wake every couple minutes or every n gps
>> events to log location
>> - low power audio subsystems can wake you up every 1-4 seconds (pcm)
>> or 1-4 minutes (mp3) to fetch more data
>
> Interesting!
>
> So for an mp3 playback, does an Android suspend between data fetches?
It can if the latency is long enough (which is why I point out low
power audio which is usually high latency). For low latency (system
sounds, etc) 10-25ms between buffers it's not practical to fully
suspend but we will go to the lowest power state in idle if possible.
Brian
On Thu, 5 Aug 2010, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 4:03 PM, Paul E. McKenney
> <[email protected]> wrote:
>>>> so what would wake a phone up from suspend where the phone should go back to
>>>> sleep in under a second?
>>>
>>> Here are some real-world examples from shipped android devices:
>>> - battery gauging happens every 10 minutes, need to wake long enough
>>> to chatter with the 1w interface and make sure the battery is not
>>> exploding
>>> - always on mail/im/calendar/etc sync often has network events that
>>> happen every 5-10 minutes which cause devices to briefly wake up and
>>> return to sleep
>>> - gps tracker app might wake every couple minutes or every n gps
>>> events to log location
>>> - low power audio subsystems can wake you up every 1-4 seconds (pcm)
>>> or 1-4 minutes (mp3) to fetch more data
>>
>> Interesting!
>>
>> So for an mp3 playback, does an Android suspend between data fetches?
>
> It can if the latency is long enough (which is why I point out low
> power audio which is usually high latency). For low latency (system
> sounds, etc) 10-25ms between buffers it's not practical to fully
> suspend but we will go to the lowest power state in idle if possible.
the playback is able to continue even with all the clocks stopped? that
surprises me. I would hav expected it to be able to sleep while playing
audio, but not do a full suspend.
David Lang
On Thu, Aug 5, 2010 at 5:16 PM, <[email protected]> wrote:
>>>
>>> So for an mp3 playback, does an Android suspend between data fetches?
>>
>> It can if the latency is long enough (which is why I point out low
>> power audio which is usually high latency). For low latency (system
>> sounds, etc) 10-25ms between buffers it's not practical to fully
>> suspend but we will go to the lowest power state in idle if possible.
>
> the playback is able to continue even with all the clocks stopped? that
> surprises me. I would hav expected it to be able to sleep while playing
> audio, but not do a full suspend.
Obviously not all clocks are stopped (the DSP and codec are powered
and clocked, for example), but yeah we can clock gate and power gate
the cpu and most other peripherals while audio is playing on a number
of ARM SoC designs available today (and the past few years).
Brian
2010/8/5 Rafael J. Wysocki <[email protected]>:
>>
>> Our wakelock stats currently have
>> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
>> and last_change. Not all of these are equally important (total_time is
>> most important followed by active_since), but you only have count.
>> Also as discussed before, many wakelocks/suspendblockers are not
>> associated with a struct device.
>
> OK
>
> How much of that is used in practice and what for exactly?
>
> Do you _really_ have to debug the wakelocks in drivers that much?
Debugging power related issues is pretty critical to building
competitive mobile devices.
Throughout the several months of this discussion I have been
continually scratching my head at this "debugability considered
harmful" attitude that I see in reaction to our interest in having the
ability (gated behind a config option even -- really, that'd be fine,
not everyone need enable it) to gather useful stats and examine the
state of the system.
At this point it sounds like there's no interest in the solution we
have, which works and has worked for a few years, and has been revised
10+ times based on feedback here, and no interest in providing a
solution that accomplishes similar functionality, so perhaps it's time
for us to cut our losses and just go back to maintaining our patches
instead of having the same arguments over and over again.
Brian
On Friday, August 06, 2010, Brian Swetland wrote:
> 2010/8/5 Rafael J. Wysocki <[email protected]>:
> >>
> >> Our wakelock stats currently have
> >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
> >> and last_change. Not all of these are equally important (total_time is
> >> most important followed by active_since), but you only have count.
> >> Also as discussed before, many wakelocks/suspendblockers are not
> >> associated with a struct device.
> >
> > OK
> >
> > How much of that is used in practice and what for exactly?
> >
> > Do you _really_ have to debug the wakelocks in drivers that much?
>
> Debugging power related issues is pretty critical to building
> competitive mobile devices.
Well, I don't think anyone will disagree with that.
> Throughout the several months of this discussion I have been
> continually scratching my head at this "debugability considered
> harmful" attitude that I see in reaction to our interest in having the
> ability (gated behind a config option even -- really, that'd be fine,
> not everyone need enable it) to gather useful stats and examine the
> state of the system.
The problem is what kind of stats would be actually sufficient and we haven't
seriously discussed that. You said you'd need statistics and we took that for
granted, but we didn't really go into details here.
> At this point it sounds like there's no interest in the solution we
> have, which works and has worked for a few years, and has been revised
> 10+ times based on feedback here, and no interest in providing a
> solution that accomplishes similar functionality, so perhaps it's time
> for us to cut our losses and just go back to maintaining our patches
> instead of having the same arguments over and over again.
Please remember that I also have spent considerable amount of time trying to
push your solution upstream and defending it. I might have spent that time
on other things instead, so please don't tell me about "losses".
If you want to stay in your ivory tower, that's perfectly fine by me, but
I guess that won't really benefit anyone in the long run.
Thanks,
Rafael
On Thu, 5 Aug 2010, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 5:16 PM, <[email protected]> wrote:
>>>>
>>>> So for an mp3 playback, does an Android suspend between data fetches?
>>>
>>> It can if the latency is long enough (which is why I point out low
>>> power audio which is usually high latency). For low latency (system
>>> sounds, etc) 10-25ms between buffers it's not practical to fully
>>> suspend but we will go to the lowest power state in idle if possible.
>>
>> the playback is able to continue even with all the clocks stopped? that
>> surprises me. I would hav expected it to be able to sleep while playing
>> audio, but not do a full suspend.
>
> Obviously not all clocks are stopped (the DSP and codec are powered
> and clocked, for example), but yeah we can clock gate and power gate
> the cpu and most other peripherals while audio is playing on a number
> of ARM SoC designs available today (and the past few years).
does this then mean that you have multiple variations of suspend?
for example, one where the audio stuff is left powered, and one where it
isn't?
David Lang
On Thu, Aug 5, 2010 at 6:01 PM, <[email protected]> wrote:
> On Thu, 5 Aug 2010, Brian Swetland wrote:
>> On Thu, Aug 5, 2010 at 5:16 PM, <[email protected]> wrote:
>>>>>
>>>>> So for an mp3 playback, does an Android suspend between data fetches?
>>>>
>>>> It can if the latency is long enough (which is why I point out low
>>>> power audio which is usually high latency). For low latency (system
>>>> sounds, etc) 10-25ms between buffers it's not practical to fully
>>>> suspend but we will go to the lowest power state in idle if possible.
>>>
>>> the playback is able to continue even with all the clocks stopped? that
>>> surprises me. I would hav expected it to be able to sleep while playing
>>> audio, but not do a full suspend.
>>
>> Obviously not all clocks are stopped (the DSP and codec are powered
>> and clocked, for example), but yeah we can clock gate and power gate
>> the cpu and most other peripherals while audio is playing on a number
>> of ARM SoC designs available today (and the past few years).
>
> does this then mean that you have multiple variations of suspend?
>
> for example, one where the audio stuff is left powered, and one where it
> isn't?
While the cpu (and the bulk of the system) is suspended, it's not
uncommon for some peripherals to continue to operate -- for example a
cellular radio, gps, low power audio playback, etc. Details will vary
depending on the SoC and board design. It's not so much a different
suspend mode (the system is still suspended), just a matter of whether
a peripheral can operate independently (and if it is lower power for
it to do so).
Brian
2010/8/5 Rafael J. Wysocki <[email protected]>:
> On Friday, August 06, 2010, Arve Hj?nnev?g wrote:
>> 2010/8/5 Rafael J. Wysocki <[email protected]>:
>> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
>> >> 2010/8/4 Rafael J. Wysocki <[email protected]>:
>> >> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
>> >> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
>> >> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
>> >> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
>> >> >> >> > No! And that's precisely the issue. Android's existing behaviour could
>> >> >> >> > be entirely implemented in the form of binary that manually triggers
>> >> >> >> > suspend when (a) the screen is off and (b) no userspace applications
>> >> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
>> >> >> >> > event race. Imagine the following:
>> >> >> >> >
>> >> >> >> > 1) The policy timeout is about to expire. No applications are holding
>> >> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
>> >> >> >> > 2) A network packet arrives indicating an incoming SIP call
>> >> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
>> >> >> >> > suspending while the call is in progress
>> >> >> >> >
>> >> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
>> >> >> >> > because the voip app is an otherwise untrusted application that you've
>> >> >> >> > just told the scheduler to ignore.
>> >> >> >>
>> >> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
>> >> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
>> >> >> >
>> >> >> > Yes, I think that solves the problem. The only question then is whether
>> >> >>
>> >> >> How? By passing a timeout to pm_wakeup_event when the network driver
>> >> >> gets the packet or by passing 0. If you pass a timeout it is the same
>> >> >> as using a wakelock with a timeout and should work (assuming the
>> >> >> timeout you picked is long enough). If you don't pass a timeout it
>> >> >> does not work, since the packet may not be visible to user-space yet.
>> >> >
>> >> > Alternatively, pm_stay_awake() / pm_relax() can be used.
>> >> >
>> >>
>> >> Which makes the driver and/or network stack changes identical to using
>> >> wakelocks, right?
>> >
>> > Please refer to the Matthew's response.
>> >
>> >> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
>> >> >> > to the implementation. In other words, is there a reason we're still
>> >> >>
>> >> >> I have seen no proposed way to use cgroups that will work. If you
>> >> >> leave some processes running while other processes are frozen you run
>> >> >> into problems when a frozen process holds a resource that a running
>> >> >> process needs.
>> >> >>
>> >> >>
>> >> >> > having this conversation? :) It'd be good to have some feedback from
>> >> >> > Google as to whether this satisfies their functional requirements.
>> >> >> >
>> >> >>
>> >> >> That is "this"? The merged code? If so, no it does not satisfy our
>> >> >> requirements. The in kernel api, while offering similar functionality
>> >> >> to the wakelock interface, does not use any handles which makes it
>> >> >> impossible to get reasonable stats (You don't know which pm_stay_awake
>> >> >> request pm_relax is reverting).
>> >> >
>> >> > Why is that a problem (out of curiosity)?
>> >> >
>> >>
>> >> Not having stats or not knowing what pm_relax is undoing? We need
>> >> stats to be able to debug the system.
>> >
>> > You have the stats in struct device and they are available via sysfs.
>> > I suppose they are insufficient, but I'd like to know why exactly.
>> >
>>
>> Our wakelock stats currently have
>> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
>> and last_change. Not all of these are equally important (total_time is
>> most important followed by active_since), but you only have count.
>> Also as discussed before, many wakelocks/suspendblockers are not
>> associated with a struct device.
>
> OK
>
> How much of that is used in practice and what for exactly?
count, tells you how many times the wakelock was activated. If a
wakelock prevented suspend for a long time a large count tells you it
handled a lot of events while a small count tells you it took a long
time to process the events, or the wakelock was not released properly.
expire_count, tells you how many times the timeout expired. For the
input event wakelock in the android kernel (which has a timeout) an
expire count that matches the count tells you that someone opened an
input device but is not reading from it (this has happened several
times).
wake_count, tells you that this is the first wakelock that was
acquired in the resume path. This is currently less useful than I
would like on the Nexus One since it is usually "SMD_RPCCALL" which
does not tell me a lot.
active_since, tells you how long a a still active wakelock has been
active. If someone activated a wakelock and never released it, it will
be obvious here.
total_time, total time the wake lock has been active. This one should
be obvious.
sleep_time, total time the wake lock has been active when the screen was off.
max_time, longest time the wakelock was active uninterrupted. This
used less often, but the battery on a device was draining fast, but
the problem went away before looking at the stats this will show if a
wakelock was active for a long time.
>
> Do you _really_ have to debug the wakelocks in drivers that much?
>
Wake locks in drivers sometimes need to be debugged. If the api has no
accountability, then these problems would take forever to fix.
>> >> If the system does not suspend
>> >> at all or is awake for too long, the wakelock stats tells us which
>> >> component is at fault. Since pm_stay_awake and pm_relax does not
>> >> operate on a handle, you cannot determine how long it prevented
>> >> suspend for.
>> >
>> > Well, if you need that, you can add a counter of "completed events" into
>>
>> We need more than that (see above).
>>
>> > struct dev_pm_info and a function similar to pm_relax() that
>> > will update that counter. ?I don't think anyone will object to that change.
>> >
>>
>> What about adding a handle that is passed to all three functions?
>
> I don't think that will fly at this point.
>
Why not? I think allowing drivers to modify a global reference count
with no accountability is a terrible idea.
>> >> >> The proposed in user-space interface
>> >> >> of calling into every process that receives wakeup events before every
>> >> >> suspend call
>> >> >
>> >> > Well, ?you don't really need to do that.
>> >> >
>> >>
>> >> Only if the driver blocks suspend until user-space has read the event.
>> >> This means that for android to work we need to block suspend when
>> >> input events are not processed, but a system using your scheme needs a
>> >> pm_wakeup_event call when the input event is queued. How to you switch
>> >> between them? Do we add separate ioctls in the input device to enable
>> >> each scheme? If someone has a single threaded user space power manager
>> >> that also reads input event it will deadlock if you block suspend
>> >> until it reads the input events since you block when reading the wake
>> >> count.
>> >
>> > Well, until someone actually tries to implement a power manager in user space
>> > it's a bit vague.
>> >
>>
>> Not having clear rules for what the drivers should do is a problem.
>> The comments in your code seem to advocate using timeouts instead of
>> overlapping pm_stay_awake/pm_relax sections. I find this
>> recommendation strange given all the opposition to
>> wakelock/suspendblocker timeouts.
>
> There's no recommendation either way.
I'm referring to this paragraph:
* Second, a wakeup event may be detected by one functional unit and processed
* by another one. In that case the unit that has detected it cannot really
* "close" the "no suspend" period associated with it, unless it knows in
* advance what's going to happen to the event during processing. This
* knowledge, however, may not be available to it, so it can simply
specify time
* to wait before the system can be suspended and pass it as the second
* argument of pm_wakeup_event().
>
>> But more importantly, calling
>> pm_wakeup_event with a timeout of 0 is incompatible with the android
>> user space code,
>
> Which I don't find really relevant, sorry.
>
>> and I would prefer that the kernel interfaces would
>> encourage drivers to block suspend until user space has consumed the
>> event, which works for the android user space, instead of just long
>> enough to work with a hypothetical user space power manager.
>
> Well, that are your personal preferences, which I respect. ?I also have some
> personal preferences that are not necessarily followed by the kernel code.
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
Arve Hj?nnev?g
On Thu, 5 Aug 2010, Brian Swetland wrote:
> On Thu, Aug 5, 2010 at 6:01 PM, <[email protected]> wrote:
>> On Thu, 5 Aug 2010, Brian Swetland wrote:
>>> On Thu, Aug 5, 2010 at 5:16 PM, <[email protected]> wrote:
>>>>>>
>>>>>> So for an mp3 playback, does an Android suspend between data fetches?
>>>>>
>>>>> It can if the latency is long enough (which is why I point out low
>>>>> power audio which is usually high latency). For low latency (system
>>>>> sounds, etc) 10-25ms between buffers it's not practical to fully
>>>>> suspend but we will go to the lowest power state in idle if possible.
>>>>
>>>> the playback is able to continue even with all the clocks stopped? that
>>>> surprises me. I would hav expected it to be able to sleep while playing
>>>> audio, but not do a full suspend.
>>>
>>> Obviously not all clocks are stopped (the DSP and codec are powered
>>> and clocked, for example), but yeah we can clock gate and power gate
>>> the cpu and most other peripherals while audio is playing on a number
>>> of ARM SoC designs available today (and the past few years).
>>
>> does this then mean that you have multiple variations of suspend?
>>
>> for example, one where the audio stuff is left powered, and one where it
>> isn't?
>
> While the cpu (and the bulk of the system) is suspended, it's not
> uncommon for some peripherals to continue to operate -- for example a
> cellular radio, gps, low power audio playback, etc. Details will vary
> depending on the SoC and board design. It's not so much a different
> suspend mode (the system is still suspended), just a matter of whether
> a peripheral can operate independently (and if it is lower power for
> it to do so).
this helps, but isn't quite what I was trying to ask.
on a given piece of hardware, does suspend always leave the same
peripherals on, or do you sometimes power more things down than other
times when suspending?
David Lang
On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> On Thu, Aug 05, 2010 at 01:26:18PM -0700, [email protected] wrote:
>> On Thu, 5 Aug 2010, kevin granade wrote:
>>
>>> On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
>>>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>>>>>>
>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>>>
>>>>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>>>>>>
>>>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>
>>>>> [ . . . ]
>>>>>
>>>> however, in the case of Android I think the timeouts have to end up being
>>>> _much_ longer. Otherwise you have the problem of loading an untrusted book
>>>> reader app on the device and the device suspends while you are reading the
>>>> page.
>>>>
>>>> currently Android works around this by having a wakelock held whenever the
>>>> display is on. This seems backwards to me, the display should be on because
>>>> the system is not suspended, not the system is prevented from suspending
>>>> because the display is on.
>>>>
>>>> Rather than having the display be on causing a wavelock to be held (with the
>>>> code that is controls the display having a timeout for how long it leaves
>>>> the display on), I would invert this and have the timeout be based on system
>>>> activity, and when it decides the system is not active, turn off the display
>>>> (along with other things as it suspends)
>>>
>>> IIRC, this was a major point of their (Android's) power management
>>> policy. User input of any kind would reset the "display active"
>>> timeout, which is the primary thing keeping random untrusted
>>> user-facing programs from being suspended while in use. They seemed
>>> to consider this to be a special case in their policy, but from the
>>> kernel's point of view it is just another suspend blocker being held.
>>>
>>> I'm not sure this is the best use case to look at though, because
>>> since it is user-facing, the timeout durations are on a different
>>> scale than the ones they are really worried about. I think another
>>> category of use case that they are worried about is:
>>>
>>> (in suspend) -> wakeup due to network -> process network activity -> suspend
>>>
>>> or an example that has been mentioned previously:
>>>
>>> (in suspend) -> wakeup due to alarm for audio processing -> process
>>> batch of audio -> suspend
>>
>> when you suspend the audio will shut off, so it's sleep ->wake ->
>> sleep, not suspend
>>
>>> In both of these cases, the display may never power on (phone might
>>> beep to indicate txt message or email, audio just keeps playing), so
>>> the magnitude of the "timeout" for suspending again should be very
>>> small. Specifically, they don't want there to be a timeout at all, so
>>> as little time as possible time is spent out of suspend in addition to
>>> the time required to handle the event that caused wakeup.
>>
>> it really depnds on the frequency of the wakeups.
>>
>> if you get a network packet once every 5 min and need to wake to
>> process it, staying awake for 20 seconds after finishing procesing
>> is FAR more significant than if you get a network packet once every
>> hour. It's not just the factor of 20 that simple math would indicate
>> because the time in suspend eats power as well.
>>
>> I don't know real numbers, so these are made up for this example
>>
>> if suspend (with the cell live to receive packets) is 10ma average
>> current and full power is 500ma average current
>>
>> packets every 5 min with .1 sec wake time will eat ~13maH per hour
>>
>> packets every 5 min with 10 second wake time will eat ~37maH per hour
>>
>> packets every hour with .1 sec wake time will eat ~10maH per hour
>>
>> packets every hour with 10 sec wake time will eat ~11maH per hour
>>
>> so if you have frequent wakeups, staying awake 100 times as long
>> will cut your battery life to 1/3 what it was before.
>>
>> if your wakeups are rare, it's about a 10% hit to stay awake 100
>> times as long.
>>
>> there is a lot of room for tuning the timeouts here.
>
> Especially given different scenarios, for example, audio playback
> when the device is in airplane mode. ;-)
hmm, I've been thinking and talking in terms of two classes of cgroups,
trusted and untrusted. I wonder if it would be possible to set timeouts
for each cgroup instead)
the system would go to sleep IFF all cgroups have been idle longer than
the idle time (with -1 idle time being 'ignore this cgroup')
if this could be done you could set longer times for things designed for
user-interaction than you do for other purposes.
you could set media to 0 idle time (so that as soon as it finishes
processing the system can sleep until the next timer)
to do this, the code making the decision would have to be able to find out
the following fairly cheaply.
1. for this cgroup, what was the last time something ran
2. for this cgroup, what is the next timer set
it would be nice to get network traffic/connection stats.
so two questions.
first, what else would you need to get accumulated for the cgroup
second, is there a fairly easy way to have these stats available?
for the 'last time it ran' stat, this seems like you could have a per-cpu
variable per cgroup that's fairly cheap to update, but you would need to
take a global lock to read accuratly (the lock may be expensive enough
that it's worth trying to read the variables from the other cpu without a
lock, just to see if it's remotely possible to sleep/suspend)
with timers, is it possible to have multiple timer wheels (one per
cgroup)?
David Lang
On Thu, Aug 05, 2010 at 06:01:24PM -0700, [email protected] wrote:
> On Thu, 5 Aug 2010, Brian Swetland wrote:
>> Obviously not all clocks are stopped (the DSP and codec are powered
>> and clocked, for example), but yeah we can clock gate and power gate
>> the cpu and most other peripherals while audio is playing on a number
>> of ARM SoC designs available today (and the past few years).
> does this then mean that you have multiple variations of suspend?
> for example, one where the audio stuff is left powered, and one where it
> isn't?
This was the core of the issue I was raising in the last thread about
this (the one following the rename to suspend blockers). Essentially
what happens in a mainline context is that some subsystems can with
varying degress of optionality ignore some or all of the instruction to
suspend and keep bits of the system alive during suspend.
Those that stay alive will either have per subsystem handling or will be
outside the direct control of the kernel entirely (the modem is a good
example of the latter case in many systems - in terms of the software
it's essentially a parallel computer that's sitting in the system rather
than a perhiperal of the AP).
On Fri, Aug 06, 2010 at 01:07:47AM -0700, [email protected] wrote:
> on a given piece of hardware, does suspend always leave the same
> peripherals on, or do you sometimes power more things down than other
> times when suspending?
Different bits of hardware get powered down depending on current system
state. In the audio case (which is so far as I know the only case for
this sort of stuff that currently does anything in mainline) we'll keep
alive any active paths (that is, paths carrying live audio) between
endpoints in the audio subsystem which have been explicitly marked as
staying alive during suspend. Other audio paths will be powered down
when the system suspends. During normal run time only paths that are
active will be powered up.
On Thu, Aug 05, 2010 at 06:29:27PM -0700, Arve Hj?nnev?g wrote:
> sleep_time, total time the wake lock has been active when the screen was off.
This one seems a little odd, and won't make sense on some devices like
those with E Ink displays or those which don't have screens at all. I
guess it's really focused on metering when the user is not actively
interacting with the device?
On Thu, Aug 05, 2010 at 06:29:27PM -0700, Arve Hj?nnev?g wrote:
> 2010/8/5 Rafael J. Wysocki <[email protected]>:
> > On Friday, August 06, 2010, Arve Hj?nnev?g wrote:
> >> 2010/8/5 Rafael J. Wysocki <[email protected]>:
> >> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> >> 2010/8/4 Rafael J. Wysocki <[email protected]>:
> >> >> > On Thursday, August 05, 2010, Arve Hj?nnev?g wrote:
> >> >> >> On Wed, Aug 4, 2010 at 1:56 PM, Matthew Garrett <[email protected]> wrote:
> >> >> >> > On Wed, Aug 04, 2010 at 10:51:07PM +0200, Rafael J. Wysocki wrote:
> >> >> >> >> On Wednesday, August 04, 2010, Matthew Garrett wrote:
> >> >> >> >> > No! And that's precisely the issue. Android's existing behaviour could
> >> >> >> >> > be entirely implemented in the form of binary that manually triggers
> >> >> >> >> > suspend when (a) the screen is off and (b) no userspace applications
> >> >> >> >> > have indicated that the system shouldn't sleep, except for the wakeup
> >> >> >> >> > event race. Imagine the following:
> >> >> >> >> >
> >> >> >> >> > 1) The policy timeout is about to expire. No applications are holding
> >> >> >> >> > wakelocks. The system will suspend providing nothing takes a wakelock.
> >> >> >> >> > 2) A network packet arrives indicating an incoming SIP call
> >> >> >> >> > 3) The VOIP application takes a wakelock and prevents the phone from
> >> >> >> >> > suspending while the call is in progress
> >> >> >> >> >
> >> >> >> >> > What stops the system going to sleep between (2) and (3)? cgroups don't,
> >> >> >> >> > because the voip app is an otherwise untrusted application that you've
> >> >> >> >> > just told the scheduler to ignore.
> >> >> >> >>
> >> >> >> >> I _think_ you can use the just-merged /sys/power/wakeup_count mechanism to
> >> >> >> >> avoid the race (if pm_wakeup_event() is called at 2)).
> >> >> >> >
> >> >> >> > Yes, I think that solves the problem. The only question then is whether
> >> >> >>
> >> >> >> How? By passing a timeout to pm_wakeup_event when the network driver
> >> >> >> gets the packet or by passing 0. If you pass a timeout it is the same
> >> >> >> as using a wakelock with a timeout and should work (assuming the
> >> >> >> timeout you picked is long enough). If you don't pass a timeout it
> >> >> >> does not work, since the packet may not be visible to user-space yet.
> >> >> >
> >> >> > Alternatively, pm_stay_awake() / pm_relax() can be used.
> >> >> >
> >> >>
> >> >> Which makes the driver and/or network stack changes identical to using
> >> >> wakelocks, right?
> >> >
> >> > Please refer to the Matthew's response.
> >> >
> >> >> >> > it's preferable to use cgroups or suspend fully, which is pretty much up
> >> >> >> > to the implementation. In other words, is there a reason we're still
> >> >> >>
> >> >> >> I have seen no proposed way to use cgroups that will work. If you
> >> >> >> leave some processes running while other processes are frozen you run
> >> >> >> into problems when a frozen process holds a resource that a running
> >> >> >> process needs.
> >> >> >>
> >> >> >>
> >> >> >> > having this conversation? :) It'd be good to have some feedback from
> >> >> >> > Google as to whether this satisfies their functional requirements.
> >> >> >> >
> >> >> >>
> >> >> >> That is "this"? The merged code? If so, no it does not satisfy our
> >> >> >> requirements. The in kernel api, while offering similar functionality
> >> >> >> to the wakelock interface, does not use any handles which makes it
> >> >> >> impossible to get reasonable stats (You don't know which pm_stay_awake
> >> >> >> request pm_relax is reverting).
> >> >> >
> >> >> > Why is that a problem (out of curiosity)?
> >> >> >
> >> >>
> >> >> Not having stats or not knowing what pm_relax is undoing? We need
> >> >> stats to be able to debug the system.
> >> >
> >> > You have the stats in struct device and they are available via sysfs.
> >> > I suppose they are insufficient, but I'd like to know why exactly.
> >> >
> >>
> >> Our wakelock stats currently have
> >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
> >> and last_change. Not all of these are equally important (total_time is
> >> most important followed by active_since), but you only have count.
> >> Also as discussed before, many wakelocks/suspendblockers are not
> >> associated with a struct device.
> >
> > OK
> >
> > How much of that is used in practice and what for exactly?
>
> count, tells you how many times the wakelock was activated. If a
> wakelock prevented suspend for a long time a large count tells you it
> handled a lot of events while a small count tells you it took a long
> time to process the events, or the wakelock was not released properly.
Got it!
> expire_count, tells you how many times the timeout expired. For the
> input event wakelock in the android kernel (which has a timeout) an
> expire count that matches the count tells you that someone opened an
> input device but is not reading from it (this has happened several
> times).
Ah, I hadn't considered that an power-oblivious application could take
this approach to waste power. I now better understand the purpose of
the timeouts, and have added the corresponding requirement. ;-)
> wake_count, tells you that this is the first wakelock that was
> acquired in the resume path. This is currently less useful than I
> would like on the Nexus One since it is usually "SMD_RPCCALL" which
> does not tell me a lot.
Got it!
> active_since, tells you how long a a still active wakelock has been
> active. If someone activated a wakelock and never released it, it will
> be obvious here.
This one is zero if the wakelock is not currently held, correct?
> total_time, total time the wake lock has been active. This one should
> be obvious.
Got it!
> sleep_time, total time the wake lock has been active when the screen was off.
Hmmm... The statistics for apps are collected in userspace, correct?
If so, this would be collecting the total time that suspend blockers
that were acquired by some driver have been held while the screen was
powered off. So if things were working properly, sleep_time should be
quite small -- with the exception of the suspend blocker that the
userspace daemon was using as a proxy for all of the userspace suspend
blockers.
Or am I confused about this?
> max_time, longest time the wakelock was active uninterrupted. This
> used less often, but the battery on a device was draining fast, but
> the problem went away before looking at the stats this will show if a
> wakelock was active for a long time.
Got it!
Thank you for this additional info, it really shines some light on
what you are trying to do.
One question: are these statistics enabled in production devices, are
is this a debug-only facility?
> > Do you _really_ have to debug the wakelocks in drivers that much?
> >
>
> Wake locks in drivers sometimes need to be debugged. If the api has no
> accountability, then these problems would take forever to fix.
So there is a separate set of suspend-blocker statistics collected in
userspace, correct? (The kernel probably doesn't need to care about this,
and I don't believe that I need anything more than a "yes" or "no" answer,
but just want to make sure I understand how these statistics are used.)
> >> >> If the system does not suspend
> >> >> at all or is awake for too long, the wakelock stats tells us which
> >> >> component is at fault. Since pm_stay_awake and pm_relax does not
> >> >> operate on a handle, you cannot determine how long it prevented
> >> >> suspend for.
> >> >
> >> > Well, if you need that, you can add a counter of "completed events" into
> >>
> >> We need more than that (see above).
> >>
> >> > struct dev_pm_info and a function similar to pm_relax() that
> >> > will update that counter. ?I don't think anyone will object to that change.
> >> >
> >>
> >> What about adding a handle that is passed to all three functions?
The reason you want the handle is to allow the calling code to indicate
which calling points are dealing with the same suspend-blocker entity?
Thaxn, Paul
> > I don't think that will fly at this point.
> >
>
> Why not? I think allowing drivers to modify a global reference count
> with no accountability is a terrible idea.
>
> >> >> >> The proposed in user-space interface
> >> >> >> of calling into every process that receives wakeup events before every
> >> >> >> suspend call
> >> >> >
> >> >> > Well, ?you don't really need to do that.
> >> >> >
> >> >>
> >> >> Only if the driver blocks suspend until user-space has read the event.
> >> >> This means that for android to work we need to block suspend when
> >> >> input events are not processed, but a system using your scheme needs a
> >> >> pm_wakeup_event call when the input event is queued. How to you switch
> >> >> between them? Do we add separate ioctls in the input device to enable
> >> >> each scheme? If someone has a single threaded user space power manager
> >> >> that also reads input event it will deadlock if you block suspend
> >> >> until it reads the input events since you block when reading the wake
> >> >> count.
> >> >
> >> > Well, until someone actually tries to implement a power manager in user space
> >> > it's a bit vague.
> >> >
> >>
> >> Not having clear rules for what the drivers should do is a problem.
> >> The comments in your code seem to advocate using timeouts instead of
> >> overlapping pm_stay_awake/pm_relax sections. I find this
> >> recommendation strange given all the opposition to
> >> wakelock/suspendblocker timeouts.
> >
> > There's no recommendation either way.
>
> I'm referring to this paragraph:
>
> * Second, a wakeup event may be detected by one functional unit and processed
> * by another one. In that case the unit that has detected it cannot really
> * "close" the "no suspend" period associated with it, unless it knows in
> * advance what's going to happen to the event during processing. This
> * knowledge, however, may not be available to it, so it can simply
> specify time
> * to wait before the system can be suspended and pass it as the second
> * argument of pm_wakeup_event().
>
> >
> >> But more importantly, calling
> >> pm_wakeup_event with a timeout of 0 is incompatible with the android
> >> user space code,
> >
> > Which I don't find really relevant, sorry.
> >
> >> and I would prefer that the kernel interfaces would
> >> encourage drivers to block suspend until user space has consumed the
> >> event, which works for the android user space, instead of just long
> >> enough to work with a hypothetical user space power manager.
> >
> > Well, that are your personal preferences, which I respect. ?I also have some
> > personal preferences that are not necessarily followed by the kernel code.
> >
> > Thanks,
> > Rafael
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at ?http://www.tux.org/lkml/
> >
>
>
>
> --
> Arve Hj?nnev?g
On Thu, Aug 05, 2010 at 05:29:24PM -0700, Brian Swetland wrote:
> 2010/8/5 Rafael J. Wysocki <[email protected]>:
> >>
> >> Our wakelock stats currently have
> >> (name,)count,expire_count,wake_count,active_since,total_time,sleep_time,max_time
> >> and last_change. Not all of these are equally important (total_time is
> >> most important followed by active_since), but you only have count.
> >> Also as discussed before, many wakelocks/suspendblockers are not
> >> associated with a struct device.
> >
> > OK
> >
> > How much of that is used in practice and what for exactly?
> >
> > Do you _really_ have to debug the wakelocks in drivers that much?
>
> Debugging power related issues is pretty critical to building
> competitive mobile devices.
>
> Throughout the several months of this discussion I have been
> continually scratching my head at this "debugability considered
> harmful" attitude that I see in reaction to our interest in having the
> ability (gated behind a config option even -- really, that'd be fine,
> not everyone need enable it) to gather useful stats and examine the
> state of the system.
In my case, it has not been "debuggability considered harmful", but
rather my lack of understanding of the kinds of bugs that can arise and
what information is most helpful in tracking them down. Arve's post
listing the meanings of the stats helped me quite a bit, although I am
sure that my understanding is still quite rudimentary.
> At this point it sounds like there's no interest in the solution we
> have, which works and has worked for a few years, and has been revised
> 10+ times based on feedback here, and no interest in providing a
> solution that accomplishes similar functionality, so perhaps it's time
> for us to cut our losses and just go back to maintaining our patches
> instead of having the same arguments over and over again.
And this brings up another aspect of Android requirements. Mainlining
Android features is not necessarily an all-or-nothing proposition. Here
is a prototype list of degrees of mainlining, along with at least a few
of the benefits and difficulties of each level:
o Mainline that provides exactly what Android needs.
This is of course the best case, but, as you may have noticed,
might not be easy to achieve. The plain fact is that Linux
must support a wide variety of workloads, so some give-and-take
is usually required.
o Mainline that exactly matches the ideal API, but which fails
to implement some feature or another.
This is still not bad. You have to carry a specific patch to
provide the feature(s), but all the calling sites are carried
upstream in mainline.
o Mainline provides something that is close to the ideal API, but
some additional constant arguments are required.
This is not so good, but at least the drivers can be upstreamed
and the changes required to get to an Android-ready kernel
are fairly simple.
o Mainline provides something, but Android requires changes to the
supplied API which require additional data to be passed from
call site to call site.
Again, at least drivers can be upstreamed, but the changes required
to get to an Android-ready kernel are a bit more involved.
o Mainline provides a stubbed-out API.
Once again, the drivers can at least be upstreamed, but Android
is the only project validating the placement of calls to the
API. This means that changes to the drivers are likely to
mess up the placement of the call sites. Therefore, getting
to an Android-ready kernel requires careful inspection of the
drivers to adjust for bugs introduced by others.
o Mainline provides nothing.
Status quo. This means that some other group will likely
introduce the required functionality in an incremental fashion.
This process will likely fail to take Android's needs into
account, probably leading to...
o Mainline provides functionality that is similar to what
Android needs, but in a completely incompatible manner
that cannot be used easily (or perhaps at all) by Android.
My guess is that there is value to Android in a number of the non-perfect
cases.
Thanx, Paul
On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
> On Thu, Aug 05, 2010 at 06:01:24PM -0700, [email protected] wrote:
> > On Thu, 5 Aug 2010, Brian Swetland wrote:
>
> >> Obviously not all clocks are stopped (the DSP and codec are powered
> >> and clocked, for example), but yeah we can clock gate and power gate
> >> the cpu and most other peripherals while audio is playing on a number
> >> of ARM SoC designs available today (and the past few years).
>
> > does this then mean that you have multiple variations of suspend?
>
> > for example, one where the audio stuff is left powered, and one where it
> > isn't?
>
> This was the core of the issue I was raising in the last thread about
> this (the one following the rename to suspend blockers). Essentially
> what happens in a mainline context is that some subsystems can with
> varying degress of optionality ignore some or all of the instruction to
> suspend and keep bits of the system alive during suspend.
>
> Those that stay alive will either have per subsystem handling or will be
> outside the direct control of the kernel entirely (the modem is a good
> example of the latter case in many systems - in terms of the software
> it's essentially a parallel computer that's sitting in the system rather
> than a perhiperal of the AP).
This underscores a basic difference between servers and these embedded
devices. When you suspend a server, it is doing nothing, because servers
rely very heavily on the CPUs. In contrast, many embedded devices can
perform useful work even when the CPUs are completely powered down.
Thanx, Paul
On Fri, Aug 06, 2010 at 01:29:57AM -0700, [email protected] wrote:
> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>
> >On Thu, Aug 05, 2010 at 01:26:18PM -0700, [email protected] wrote:
> >>On Thu, 5 Aug 2010, kevin granade wrote:
> >>
> >>>On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
> >>>>On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> >>>>
> >>>>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
> >>>>>>
> >>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>>>>>
> >>>>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
> >>>>>>>>
> >>>>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>>>
> >>>>>[ . . . ]
> >>>>>
> >>>>however, in the case of Android I think the timeouts have to end up being
> >>>>_much_ longer. Otherwise you have the problem of loading an untrusted book
> >>>>reader app on the device and the device suspends while you are reading the
> >>>>page.
> >>>>
> >>>>currently Android works around this by having a wakelock held whenever the
> >>>>display is on. This seems backwards to me, the display should be on because
> >>>>the system is not suspended, not the system is prevented from suspending
> >>>>because the display is on.
> >>>>
> >>>>Rather than having the display be on causing a wavelock to be held (with the
> >>>>code that is controls the display having a timeout for how long it leaves
> >>>>the display on), I would invert this and have the timeout be based on system
> >>>>activity, and when it decides the system is not active, turn off the display
> >>>>(along with other things as it suspends)
> >>>
> >>>IIRC, this was a major point of their (Android's) power management
> >>>policy. User input of any kind would reset the "display active"
> >>>timeout, which is the primary thing keeping random untrusted
> >>>user-facing programs from being suspended while in use. They seemed
> >>>to consider this to be a special case in their policy, but from the
> >>>kernel's point of view it is just another suspend blocker being held.
> >>>
> >>>I'm not sure this is the best use case to look at though, because
> >>>since it is user-facing, the timeout durations are on a different
> >>>scale than the ones they are really worried about. I think another
> >>>category of use case that they are worried about is:
> >>>
> >>>(in suspend) -> wakeup due to network -> process network activity -> suspend
> >>>
> >>>or an example that has been mentioned previously:
> >>>
> >>>(in suspend) -> wakeup due to alarm for audio processing -> process
> >>>batch of audio -> suspend
> >>
> >>when you suspend the audio will shut off, so it's sleep ->wake ->
> >>sleep, not suspend
> >>
> >>>In both of these cases, the display may never power on (phone might
> >>>beep to indicate txt message or email, audio just keeps playing), so
> >>>the magnitude of the "timeout" for suspending again should be very
> >>>small. Specifically, they don't want there to be a timeout at all, so
> >>>as little time as possible time is spent out of suspend in addition to
> >>>the time required to handle the event that caused wakeup.
> >>
> >>it really depnds on the frequency of the wakeups.
> >>
> >>if you get a network packet once every 5 min and need to wake to
> >>process it, staying awake for 20 seconds after finishing procesing
> >>is FAR more significant than if you get a network packet once every
> >>hour. It's not just the factor of 20 that simple math would indicate
> >>because the time in suspend eats power as well.
> >>
> >>I don't know real numbers, so these are made up for this example
> >>
> >>if suspend (with the cell live to receive packets) is 10ma average
> >>current and full power is 500ma average current
> >>
> >>packets every 5 min with .1 sec wake time will eat ~13maH per hour
> >>
> >>packets every 5 min with 10 second wake time will eat ~37maH per hour
> >>
> >>packets every hour with .1 sec wake time will eat ~10maH per hour
> >>
> >>packets every hour with 10 sec wake time will eat ~11maH per hour
> >>
> >>so if you have frequent wakeups, staying awake 100 times as long
> >>will cut your battery life to 1/3 what it was before.
> >>
> >>if your wakeups are rare, it's about a 10% hit to stay awake 100
> >>times as long.
> >>
> >>there is a lot of room for tuning the timeouts here.
> >
> >Especially given different scenarios, for example, audio playback
> >when the device is in airplane mode. ;-)
>
> hmm, I've been thinking and talking in terms of two classes of
> cgroups, trusted and untrusted. I wonder if it would be possible to
> set timeouts for each cgroup instead)
>
> the system would go to sleep IFF all cgroups have been idle longer
> than the idle time (with -1 idle time being 'ignore this cgroup')
>
> if this could be done you could set longer times for things designed
> for user-interaction than you do for other purposes.
>
> you could set media to 0 idle time (so that as soon as it finishes
> processing the system can sleep until the next timer)
>
> to do this, the code making the decision would have to be able to
> find out the following fairly cheaply.
>
> 1. for this cgroup, what was the last time something ran
>
> 2. for this cgroup, what is the next timer set
>
> it would be nice to get network traffic/connection stats.
>
> so two questions.
>
> first, what else would you need to get accumulated for the cgroup
>
> second, is there a fairly easy way to have these stats available?
>
> for the 'last time it ran' stat, this seems like you could have a
> per-cpu variable per cgroup that's fairly cheap to update, but you
> would need to take a global lock to read accuratly (the lock may be
> expensive enough that it's worth trying to read the variables from
> the other cpu without a lock, just to see if it's remotely possible
> to sleep/suspend)
>
> with timers, is it possible to have multiple timer wheels (one per
> cgroup)?
I apologize in advance for what I am about to write, but...
If you continue in this vein, you are likely to make suspend blockers
look very simple and natural. ;-)
Thanx, Paul
On Fri, Aug 06, 2010 at 10:22:26AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
> > this (the one following the rename to suspend blockers). Essentially
> > what happens in a mainline context is that some subsystems can with
> > varying degress of optionality ignore some or all of the instruction to
> > suspend and keep bits of the system alive during suspend.
> This underscores a basic difference between servers and these embedded
> devices. When you suspend a server, it is doing nothing, because servers
> rely very heavily on the CPUs. In contrast, many embedded devices can
> perform useful work even when the CPUs are completely powered down.
Well, not really from the Linux point of view. It's not massively
different to something like keeping an ethernet controller sufficiently
alive to allow it to provide wake on LAN functionality while the system
is suspended in terms of what Linux has to do, and quite a few servers
have lights out management systems which aren't a million miles away
from the modem on a phone in terms of their relationship with the host
computer.
On Fri, Aug 06, 2010 at 06:33:25PM +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 10:22:26AM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
>
> > > this (the one following the rename to suspend blockers). Essentially
> > > what happens in a mainline context is that some subsystems can with
> > > varying degress of optionality ignore some or all of the instruction to
> > > suspend and keep bits of the system alive during suspend.
>
> > This underscores a basic difference between servers and these embedded
> > devices. When you suspend a server, it is doing nothing, because servers
> > rely very heavily on the CPUs. In contrast, many embedded devices can
> > perform useful work even when the CPUs are completely powered down.
>
> Well, not really from the Linux point of view. It's not massively
> different to something like keeping an ethernet controller sufficiently
> alive to allow it to provide wake on LAN functionality while the system
> is suspended in terms of what Linux has to do, and quite a few servers
> have lights out management systems which aren't a million miles away
> from the modem on a phone in terms of their relationship with the host
> computer.
The wake-on-LAN and the lights-out management systems are indeed
interesting examples, and actually pretty good ones. The reason I
excluded them is that they don't do any application processing -- their
only purpose is the care and feeding of the system itself. In contrast,
the embedded processors are able to do significant applications processing
(e.g., play back music) while any CPUs are completely shut down and most
of the memory is powered down as well.
Thanx, Paul
On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> count, tells you how many times the wakelock was activated. If a
> wakelock prevented suspend for a long time a large count tells you it
> handled a lot of events while a small count tells you it took a long
> time to process the events, or the wakelock was not released properly.
As noted, we already have this.
> expire_count, tells you how many times the timeout expired. For the
> input event wakelock in the android kernel (which has a timeout) an
> expire count that matches the count tells you that someone opened an
> input device but is not reading from it (this has happened several
> times).
This is a little tricky. Rafael's model currently does not allow
wakeup events started by pm_wakeup_event() to be cancelled any way
other than by having their timer expire. This essentially means that
for some devices, expire_count will always be the same as count and for
others it will always be 0. To change this would require adding an
extra timer struct, which could be done (in fact, an earlier version of
the code included it). It would be nice if we could avoid the need.
Does Android use any kernel-internal wakelocks both with a timer and
with active cancellation?
> wake_count, tells you that this is the first wakelock that was
> acquired in the resume path. This is currently less useful than I
> would like on the Nexus One since it is usually "SMD_RPCCALL" which
> does not tell me a lot.
This could be done easily enough, but if it's not very useful then
there's no point.
> active_since, tells you how long a a still active wakelock has been
> active. If someone activated a wakelock and never released it, it will
> be obvious here.
Easily added. But you didn't mention any field saying whether the
wakelock is currently active. That could be added too (although it
would be racy -- but for detecting unreleased wakelocks you wouldn't
care).
> total_time, total time the wake lock has been active. This one should
> be obvious.
Also easily added.
> sleep_time, total time the wake lock has been active when the screen was off.
Not applicable to general systems. Is there anything like it that
_would_ apply in general?
> max_time, longest time the wakelock was active uninterrupted. This
> used less often, but the battery on a device was draining fast, but
> the problem went away before looking at the stats this will show if a
> wakelock was active for a long time.
Again, easily added. The only drawback is that all these additions
will bloat the size of struct device. Of course, that's why you used
separately-allocated structures for your wakelocks. Maybe we can
change to do the same; it seems likely that the majority of device
structures won't ever be used for wakeup events.
> >> and I would prefer that the kernel interfaces would
> >> encourage drivers to block suspend until user space has consumed the
> >> event, which works for the android user space, instead of just long
> >> enough to work with a hypothetical user space power manager.
Rafael doesn't _discourage_ drivers from doing this. However you have
to keep in mind that many kernel developers are accustomed to working
on systems (mostly PCs) with a different range of hardware devices from
embedded systems like your phones. With PCI devices(*), for example,
there's no clear point where a wakeup event gets handed off to
userspace.
On the other hand, there's no reason the input layer shouldn't use
pm_stay_awake and pm_relax. It simply hasn't been implemented yet.
Alan Stern
(*) Speaking of PCI devices, I'm not convinced that the way Rafael is
using the pm_wakeup_event interface in the PCI core is entirely
correct. The idea is to resolve the race between wakeup events and
suspend. The code assumes that a wakeup event will be consumed in 100
ms or less, which is a reasonable assumption.
But what sorts of things qualify as wakeup events? Right now, the code
handles only events coming by way of the PME# signal (or its platform
equivalent). But that signal usually gets activated only when a PCI
device is in a low-power mode; if the device is at full power then it
simply generates an IRQ. It's the same event, but reported to the
kernel in a different way. So consider...
Case 1: The system is suspending and the PCI device has already been
placed in D3hot when an event occurs. PME# is activated,
the wakeup event is reported, the suspend is aborted, and the
system won't try to suspend again for at least 100 ms. Good.
Case 2: The system is running normally and the PCI device is at full
power when an event occurs. PME# isn't activated and
pm_wakeup_event doesn't get called. Then when the system
tries to suspend 25 ms later, there's nothing to prevent it
even though the event is still being processed. Bad.
In case 2 the race has not been resolved. It seems to me that the
only proper solution is to call pm_wakeup_event for _every_ PCI
interrupt. This may be too much to add to a hot path, but what's the
alternative?
On Friday, August 06, 2010, Alan Stern wrote:
> On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
...
> But what sorts of things qualify as wakeup events? Right now, the code
> handles only events coming by way of the PME# signal (or its platform
> equivalent). But that signal usually gets activated only when a PCI
> device is in a low-power mode; if the device is at full power then it
> simply generates an IRQ. It's the same event, but reported to the
> kernel in a different way. So consider...
>
> Case 1: The system is suspending and the PCI device has already been
> placed in D3hot when an event occurs. PME# is activated,
> the wakeup event is reported, the suspend is aborted, and the
> system won't try to suspend again for at least 100 ms. Good.
>
> Case 2: The system is running normally and the PCI device is at full
> power when an event occurs. PME# isn't activated and
> pm_wakeup_event doesn't get called. Then when the system
> tries to suspend 25 ms later, there's nothing to prevent it
> even though the event is still being processed. Bad.
>
> In case 2 the race has not been resolved. It seems to me that the
> only proper solution is to call pm_wakeup_event for _every_ PCI
> interrupt. This may be too much to add to a hot path, but what's the
> alternative?
Arguably not every PCI interrupt should be regarded as a wakeup event, so
I think we can simply say in the cases when that's necessary the driver should
be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
appropriate.
My patch only added it to the bus-level code which covered the PME-based
wakeup events that _cannot_ be handled by device drivers.
Thanks,
Rafael
On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> On Fri, Aug 06, 2010 at 01:29:57AM -0700, [email protected] wrote:
>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Thu, Aug 05, 2010 at 01:26:18PM -0700, [email protected] wrote:
>>>> On Thu, 5 Aug 2010, kevin granade wrote:
>>>>
>>>>> On Thu, Aug 5, 2010 at 10:46 AM, <[email protected]> wrote:
>>>>>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>>>>>
>>>>>>> On Wed, Aug 04, 2010 at 10:18:40PM -0700, [email protected] wrote:
>>>>>>>>
>>>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Aug 04, 2010 at 05:25:53PM -0700, [email protected] wrote:
>>>>>>>>>>
>>>>>>>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>>>>
>>>>>>> [ . . . ]
>>>>>>>
>>
>> it would be nice to get network traffic/connection stats.
>>
>> so two questions.
>>
>> first, what else would you need to get accumulated for the cgroup
>>
>> second, is there a fairly easy way to have these stats available?
>>
>> for the 'last time it ran' stat, this seems like you could have a
>> per-cpu variable per cgroup that's fairly cheap to update, but you
>> would need to take a global lock to read accuratly (the lock may be
>> expensive enough that it's worth trying to read the variables from
>> the other cpu without a lock, just to see if it's remotely possible
>> to sleep/suspend)
>>
>> with timers, is it possible to have multiple timer wheels (one per
>> cgroup)?
>
> I apologize in advance for what I am about to write, but...
>
> If you continue in this vein, you are likely to make suspend blockers
> look very simple and natural. ;-)
if that's the case then they should be implemented :-)
on the other hand, this may be something that's desirable for
idle-low-power as well.
David Lang
Final report from this particular angel-free zone for the time being...
This is the third and final version of my Android requirements list
(last version available at http://lkml.org/lkml/2010/8/4/409). Again,
this email is an attempt to present the Android guys' requirements, based
on my interpretation of LKML discussions. This past week's discussion
was quite productive, and I thank everyone who took part.
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 our collective understanding of what the Android
folks' requirements are. That said, I do discuss example mechanisms
where needed to clarify the meaning of the requirements. This should
not be interpreted as a preference for any given example mechanism.
Thanx, Paul
------------------------------------------------------------------------
CONTENTS
o DEFINITIONS
o CATEGORIES OF APPLICATION BEHAVIOR
o REQUIREMENTS
o NICE-TO-HAVES
o APPARENT NON-REQUIREMENTS
o SUGGESTED USAGE
o POWER-OPTIMIZED APPLICATIONS
o OTHER EXAMPLE APPLICATIONS
o ACKNOWLEDGMENTS
DEFINITIONS
These have been updated based on LKML and linux-pm discussions. The names
are probably still sub-optimal, but incremental progress is nevertheless
a very good thing.
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
externally powered PCs. Many other people seemed to instead be
thinking in terms of an ill-conceived or useless application,
perhaps exemplified by "bouncing cows".
This document uses "power-oblivious applications" to mean
applications that are well-designed and well-implemented in in
general, but which do not take power consumption or battery life
into account.
o "PM-driving 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 processes are classified as power aware. Android uses a
user-level daemon to classify app-store apps as PM-driving or not.
More generally, PM-driving applications are those that have
permission to exert some control over the system's sleep state.
Note that an application might be power-oblivious on one
Android device and PM-driving on another, depending on whether
the user allows that application to acquire suspend blockers.
The classification might even change over time. For example,
a user might give an application PM-driving status initially,
but change his or her mind after some experience with that
application.
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
PM-driving applications that have been aggressively tuned to
reduce power consumption.
o Individual devices in an embedded system can enter "device
low-power states" when not in use.
o The system as a whole can enter a "system sleep state" when
the system as a whole is not in use. Suspend blockers are about
system sleep states rather than device low-power states.
o There was much discussion of "idle" (AKA "deep idle") and
"suspend" (as in current Linux-kernel suspend operations).
The following characteristics distinguish "idle" from "suspend":
1. Idle states are entered by a given CPU only there are no
runnable tasks for that CPU. In contrast, opportunistic
suspend can halt the entire system even when there
are tasks that are ready, willing, and able to run.
(But please note that this might not apply to real-time
tasks.)
Freezing of subsets of applications is somewhat related
to the idle/suspend discussion, but is covered in a
later section of this document.
2. There can be a set of input events that do not bring
the system out of suspend, but which would bring the
system out of idle. Exactly which events are in this
set depends both on hardware capabilities and on the
platform/application policy. For example, on one of
the Android-based smartphones, touchscreen input is
ignored when the system is suspended, but is handled
when idle.
3. The system comes out of idle when a timer expires. In
contrast, timers might or might not bring the system
out of suspend, depending on both hardware capabilities
and platform/application policy.
CATEGORIES OF APPLICATION BEHAVIOR
There are a number of categories of application behavior with respect
to power management and energy efficiency. These can be classified via
the following questions: (1) What degree of control is an application
permitted over its own behavior? (2) What degree of control is an
application permitted over the power state of individual devices within
the system? (3) What degree of control is an application permitted
over the system sleep state? (4) To what degree has the application
been tuned to reduce its power consumption, either in isolation or in
conjunction with other applications that might be running concurrently?
These categories are discussed below.
o What degree of control is an application permitted over its
own behavior?
The Linux kernel already has many controls over application
behavior:
o the CAP_ capabilities from include/linux/capability.h.
o Processes can be assigned to multiple groups, allowing
them privileged access to portions of the filesystem.
o The chroot() system call limits a process's access to the
specified subtree of the filesystem.
o The ulimit facility can limit CPU consumption, number
of processes, memory, etc. on a per-user basis. The
rlimit facility has similar effects on a per-process
basis.
o The mlockall() system call provides privileged access
to memory, avoiding page-fault overhead.
But more relevant to this discussion, real-time processes are
permitted a much higher degree of control over the timing of their
execution than are non-real-time processes. However, suspending
the system destroys any pretense of offering real-time guarantees,
which might explain much of the annoyance towards suspend blockers
from the real-time and scheduler folks. For but one example,
Peter Zijlstra suggested that he would merge a patch that acquired
a suspend blocker any time that the runqueues were non-empty.
My first reaction was amusement at this vintage Peter Zijlstra
response, and my second reaction was that it was a futile gesture,
as the Android guys would simply back out any such change.
After more thought, however, a variation of Peter's approach
might well be the key to resolving this tension between
real-time response on the one hand and Android's desire to
conserve power at any cost on the other. Given that suspending
destroys real-time response, why not acquire a suspend blocker
any time there is a user-created real-time task in the system,
whether runnable or not? Of course, a simpler approach would
be to make Android's OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT.
o What degree of control is an application permitted over the power
state of individual devices within the system?
Is the application in question permitted to power down the
CPU or peripheral devices? As more of the power control is
automated based on usage, it is possible that this question will
become less relevant. The longer the latency and the greater
the energy consumption of a power-up/power-down sequence for
a given device, the less suitable that device is for automatic
power-up/power-down decisions. Cache SRAMs and main-memory
DRAM tend to be less suitable for automation for this reason.
o What degree of control is an application permitted over the
system sleep state?
Is the application permitted to suspend the device? Or in the
case of Android, is the application permitted to acquire a
suspend blocker, which prevents the device from being suspended?
o To what degree has the application been tuned to reduce its
power consumption, either in isolation or in conjunction with
other applications that might be running concurrently?
See the "POWER-OPTIMIZED APPLICATIONS" section below for more
detail on the lengths that embedded developers go to in order
to conserve power -- or, more accurately, to extend battery life.
REQUIREMENTS
o Reduce the system's power consumption in order to (1) extend
battery life and (2) preserve state until external power can
be obtained.
o It is necessary to be able to use power-oblivious 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 external power or
(2) relatively undemanding laptop battery-lifetime expectations.
The system must be capable of running these power-oblivious
applications without requiring that these applications be
modified, and must be capable of reasonable power efficiency
even when power-oblivious applications are in use.
In other words, it must be possible to automate the incorporation
of a power-oblivious application into the Android environment,
but without significantly degrading battery lifetime.
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 it is highly desirable that the
application also be prevented from consuming power computing
something that will not be displayed. Furthermore, whatever
mechanism is used must operate on power-oblivious applications
that do not use blocking system calls.
There might well be similar requirements for other output-only
devices, as noted by Alan Stern.
o In order to avoid overrunning hardware and/or kernel buffers,
and to minimize response latencies, designated 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 sleep state is received while the system is
transitioning into a sleep state, the system must transition
back out of the sleep state so that it can hand the user
input off to the corresponding application.
Other input events do not force a wakeup, and such input events
-can- be lost due to buffer overflow in hardware or the kernel.
The response latency to such input events can of course be
unbounded.
o Because Android acquires a suspend blocker as soon as an
input event is noticed and holds it until some application
reads that input event, there must be a way to cause the
suspend blocker to timeout. If there was no such timeout
facility, a power-oblivious application could block suspend by
opening an input device and then refusing to ever read from it.
(Yes, this can be considered to be a energy-efficiency bug in
the power-oblivious application. Please see the statistics
requirement below.)
o The API must provide a way for PM-driving applications that
receive events to keep themselves running until they have been
able to process those events.
o Statistics of the power-control actions taken by PM-driving
applications must be provided. Statistics are aggregated by name,
which is passed by the application in through the suspend-blocker
interface. The following specific statistics are collected in
the kernel, in roughly decreasing order of importance:
o total_time, which accumulates the total amount of time
that the corresponding suspend blocker has been held.
o active_since, which tracks how long a suspend blocker has
been held since it was last acquired, or (presumably) zero
if it is not currently held.
o count, which is the number of times that the suspend
blocker has been acquired. This is useful in combination
with total_time, as it allows you to calculate the
average hold time for the suspend blocker.
o expire_count, which is the number of times that the
suspend blocker has timed out. This indicates that
some application has an input device open, but is
not reading from it, which is a bug, as noted earlier.
o max_time, which is the longest hold time for the suspend
blocker. This allows finding cases where suspend blockers
are held for too long, but are eventually released.
(In contrast, active_since is more useful in the
held-forever case.)
o sleep_time, which is the total time that the suspend
blocker was held while the display was powered off.
(This might have interesting implications should E-ink
displays every become capable of full-motion color video,
but it is easy to imagine that the definition of "powered
off" would then include only those times during which
the display wasn't actively being updated.)
o wake_count, which is the number of times that the
suspend blocker was the first to be acquired in the
resume path. This is less than useful on some
Android platforms; Arve is dissatisfied with it
on Nexus One.
Presumably, the userspace code collects similar statistics on
application suspend-blocker activity, but that is out of the scope
of this document, which focuses instead on kernel requirements.
Given that the overhead of maintaining these statistics is
quite low, it seems that it would be worthwhile to have them
enabled in production systems, for example, in order to flag
power-buggy applications that the user has naively downloaded.
o Some PM-driving applications use power-oblivious infrastructure
code. This means that a PM-driving application must have
some way, whether explicit or implicit, to ensure that any
power-oblivious infrastructure code is permitted to run when a
PM-driving application needs it to run.
o If no PM-driving or power-optimized application are indicating
a need for the system to remain operating, the system is permitted
(even encouraged!) to suspend all execution, regardless of the
state of power-oblivious applications. (This requirement did
appear to be somewhat controversial, both in terms of what is
meant by "runnable" and in terms of what constitutes "execution".)
In Android, this is implemented by suspending even while
PM-driving or power-optimized applications are active, -unless-
a suspend blocker is held.
o Transition to system sleep state must be power-efficient.
In particular, methods based on repeated attempts to suspend
are considered to be too inefficient to be useful.
o Transition to system sleep state must occur very soon after
all PM-driving and power-optimized applications have indicated
that they have no need for the system to remain operating.
Quick transition is expecially important in cases where the wakeup
was momentary, for example, when processing sporadic network
input or processing widely spaced batches of audio output.
For an example of the latter, MP3 playback allows 1-4 minute
spacing between bursts of CPU activity).
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 sleep 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 The API that controls the system sleep 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 sleep 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. According to Brian
Swetland:
For Java/Dalvik apps, the wakelock API is pertty
high level -- it talks to a service via RPC (Binder)
that actually interacts with the kernel. Changing the
basic kernel<->userspace interface (within reason) is
not unthinkable. For example, Arve's suspend_blocker
patch provides a device interface rather than the proc
interface the older wakelock patches use. We'd have to
make some userspace changes to support that but they're
pretty low level and minor.
In the current model, only a few processes need to
specifically interact with the kernel (the power
management service in the system_server, possibly the
media_server and the radio interface glue). A model where
every process needs to have a bunch of instrumentation is
not very desirable from our point of view. We definitely
do need reasonable statistics in order to enable debugging
and to enable reporting to endusers (through the Battery
Usage UI) what's keeping the device awake.
o Any mechanism that freezes some subset of the applications must
ensure that none of the frozen applications hold any user-level
resources, such as pthread mutexes. The reason for this is that
freezing an application that holds a shared pthread mutex will
result in an application-level hang should some unfrozen process
attempt to acquire that same pthread mutex. Note that although
the current cgroup freezer ensures that frozen applications do not
hold any kernel-level mutexes (at least assuming these mutexes
are not wrongly held when returning to user-level execution),
it currently does nothing to prevent freezing processes holding
pthread mutexes. (There are some proposals to address this issue.)
NICE-TO-HAVES
o It would be nice to be able to identify power-oblivious
applications that never were depended on by PM-driving
applications. This particular class of power-oblivious
applications could be shut down when the screen blanks even
if some PM-driving application was preventing the system from
powering down.
There are two obstacles to meeting this requirement:
1. There must be a reliable way to identify such
applications. This should be doable, for example, the
application might be tagged by its developer.
2. There must be a reliable way to freeze them such
that no frozen application holds a resource that
might be contended by a non-frozen application.
Although the cgroup freezer does ensure that frozen
tasks hold no kernel-level resources, it currently does
nothing to ensure that no user-level resources are held.
There are some alternative proposals, which might or
might not be more successful:
a. Unfreeze this group periodically to ensure
that any such resource is eventually released,
while keeping power consumption down to a dull
roar.
b. Perform the freeze at application level, where
it is possible to determine whether an
application-level resource is held.
o Any initialization of the API that controls the system power
state should be unconditional, so as to be free from failure.
Such unconditional initialization reduces the intrusiveness of
the Android patchset.
APPARENT NON-REQUIREMENTS
o Transitioning to system sleep states need not be highly scalable,
as evidenced by the global locks. (If you believe that high
scalability 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.)
That said, it should not be hard to provide a highly scalable
implementation of suspend blockers, especially if large systems
are allowed to take their time suspending themselves.
o Conserving power in the WiFi and cellular telephony networks.
At the moment, the focus is on increased battery life in the
handheld device, perhaps even at the expense of additional
power consumed by the externally powered WiFi and cell-telephony
equipment.
o Synchronizing wakeups of unrelated applications. This is of
course an important requirement for power savings overall, but
seems to be left to other mechanisms (e.g., timer aggregation)
by the Android folks. Although one could implement suspend
blockers so as to aggregate timers after a sufficiently long
suspension, there are problems with this approach:
o There would be a "thundering herd" problem just after
resume completed as almost every timer in the system
would expire simultaneously.
o The applications would not necessarily stay aggregated
without some other mechanism helping out.
SUGGESTED USAGE
These are constraints that the developer is expected to abide by,
"for best results" and all that.
o When a PM-driving application is preventing the system from
shutting down, and is also waiting on a power-oblivious
application, the PM-driving application should set a timeout
to handle the possibility that the power-oblivious application
might halt or otherwise fail.
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 sleep 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 achieve 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. Provide "heartbeat" services that allow applications to
synchronize with each other. This seems most applicable for
applications that run infrequently, such as email-checking and
location-service applications.
5. 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.
6. 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 PM-driving (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-oblivious 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.
ACKNOWLEDGMENTS
Of course, just because I acknowledge their contributions does
not necessarily mean that I think they agree with my assessment
of the requirements behind suspend blockers. ;-)
Nevertheless, I am grateful for any and all feedback, whatever
the form of that feedback might be. I am new to this area, and
have much to learn.
Alan Stern
Anca Emanuel
Arjan van de Ven
Arve Hj?nnev?g
Brian Swetland
David Brownell
David Lang
Florian Mickler
James Bottomley
Kevin Granade
Mark Brown
Matt Helsley
Matthew Garrett
Mikael Abrahamsson
Olivier Galibert
Paul Menage
Pavel Machek
Rafael J. Wysocki
Richard Woodruff
Ted Ts'o
On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> On Fri, Aug 06, 2010 at 06:33:25PM +0100, Mark Brown wrote:
>> On Fri, Aug 06, 2010 at 10:22:26AM -0700, Paul E. McKenney wrote:
>>> On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
>>
>>>> this (the one following the rename to suspend blockers). Essentially
>>>> what happens in a mainline context is that some subsystems can with
>>>> varying degress of optionality ignore some or all of the instruction to
>>>> suspend and keep bits of the system alive during suspend.
>>
>>> This underscores a basic difference between servers and these embedded
>>> devices. When you suspend a server, it is doing nothing, because servers
>>> rely very heavily on the CPUs. In contrast, many embedded devices can
>>> perform useful work even when the CPUs are completely powered down.
>>
>> Well, not really from the Linux point of view. It's not massively
>> different to something like keeping an ethernet controller sufficiently
>> alive to allow it to provide wake on LAN functionality while the system
>> is suspended in terms of what Linux has to do, and quite a few servers
>> have lights out management systems which aren't a million miles away
>> from the modem on a phone in terms of their relationship with the host
>> computer.
>
> The wake-on-LAN and the lights-out management systems are indeed
> interesting examples, and actually pretty good ones. The reason I
> excluded them is that they don't do any application processing -- their
> only purpose is the care and feeding of the system itself. In contrast,
> the embedded processors are able to do significant applications processing
> (e.g., play back music) while any CPUs are completely shut down and most
> of the memory is powered down as well.
one other significant issue is that on the PC, things like wake-on-LAN,
lights out management cards, etc require nothing from the main system
other than power. If they do something, they are sending the signal to the
chipset, which then wakes the system up. they don't interact with the main
processor/memory/etc at all.
So as I see it, we need to do one of two things.
1. change the suspend definition to allow for some things to not be
suspended
or
2. change the sleep/low-power mode definition to have a more standardized
way of turning things off, and extend it to allow clocks to be turned off
as well (today we have things able to be turned off, drive spin-down for
example, but per comments in this thread it's all one-off methods)
to me #2 seems the better thing to do from a design/concept point of view
David Lang
one other nice-to-have (or conflicting requirement, depending on your
point of view), and I think one of the big things causing people to
dislike wavelocks, is the desire to not have to modify applications to
have them work with the infrastructure.
you sort of touch on this when you say that power oblivious applications
need to be able to be intergrated, but it goes beyond what that statement
implies.
with wavelocka, even power optimized applications need to be modified, or
the system may halt them at any time.
one thing that has been very clear over the years is that if an API only
exists on Linux, no matter how good it is, most application developers
won't use it.
In this case we are in an even worse situation, it's not only specific to
Linux, it's specific to a subset of Linux systems, and not using it will
cause no problems most of the time.
now, android is betting that the apps are all developed specifically for
the android from scratch, so having a different API is acceptable, even if
it cuts them off from the rest of the *nix applications. For a phone this
is not neccessarily an unreasonable stance, but as Android moves into the
spaces where normal applications are in use (netbooks and tablets), this
becomes a much shakier stance to take.
David Lang
On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> Date: Fri, 6 Aug 2010 15:54:53 -0700
> From: Paul E. McKenney <[email protected]>
> To: [email protected], [email protected]
> Cc: [email protected], [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected],
> [email protected], [email protected], [email protected]
> Subject: Attempted summary of suspend-blockers LKML thread, take three
>
> Final report from this particular angel-free zone for the time being...
>
> This is the third and final version of my Android requirements list
> (last version available at http://lkml.org/lkml/2010/8/4/409). Again,
> this email is an attempt to present the Android guys' requirements, based
> on my interpretation of LKML discussions. This past week's discussion
> was quite productive, and I thank everyone who took part.
>
> 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 our collective understanding of what the Android
> folks' requirements are. That said, I do discuss example mechanisms
> where needed to clarify the meaning of the requirements. This should
> not be interpreted as a preference for any given example mechanism.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> CONTENTS
>
> o DEFINITIONS
> o CATEGORIES OF APPLICATION BEHAVIOR
> o REQUIREMENTS
> o NICE-TO-HAVES
> o APPARENT NON-REQUIREMENTS
> o SUGGESTED USAGE
> o POWER-OPTIMIZED APPLICATIONS
> o OTHER EXAMPLE APPLICATIONS
> o ACKNOWLEDGMENTS
>
>
> DEFINITIONS
>
> These have been updated based on LKML and linux-pm discussions. The names
> are probably still sub-optimal, but incremental progress is nevertheless
> a very good thing.
>
> 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
> externally powered PCs. Many other people seemed to instead be
> thinking in terms of an ill-conceived or useless application,
> perhaps exemplified by "bouncing cows".
>
> This document uses "power-oblivious applications" to mean
> applications that are well-designed and well-implemented in in
> general, but which do not take power consumption or battery life
> into account.
>
> o "PM-driving 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 processes are classified as power aware. Android uses a
> user-level daemon to classify app-store apps as PM-driving or not.
> More generally, PM-driving applications are those that have
> permission to exert some control over the system's sleep state.
>
> Note that an application might be power-oblivious on one
> Android device and PM-driving on another, depending on whether
> the user allows that application to acquire suspend blockers.
> The classification might even change over time. For example,
> a user might give an application PM-driving status initially,
> but change his or her mind after some experience with that
> application.
>
> 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
> PM-driving applications that have been aggressively tuned to
> reduce power consumption.
>
> o Individual devices in an embedded system can enter "device
> low-power states" when not in use.
>
> o The system as a whole can enter a "system sleep state" when
> the system as a whole is not in use. Suspend blockers are about
> system sleep states rather than device low-power states.
>
> o There was much discussion of "idle" (AKA "deep idle") and
> "suspend" (as in current Linux-kernel suspend operations).
> The following characteristics distinguish "idle" from "suspend":
>
> 1. Idle states are entered by a given CPU only there are no
> runnable tasks for that CPU. In contrast, opportunistic
> suspend can halt the entire system even when there
> are tasks that are ready, willing, and able to run.
> (But please note that this might not apply to real-time
> tasks.)
>
> Freezing of subsets of applications is somewhat related
> to the idle/suspend discussion, but is covered in a
> later section of this document.
>
> 2. There can be a set of input events that do not bring
> the system out of suspend, but which would bring the
> system out of idle. Exactly which events are in this
> set depends both on hardware capabilities and on the
> platform/application policy. For example, on one of
> the Android-based smartphones, touchscreen input is
> ignored when the system is suspended, but is handled
> when idle.
>
> 3. The system comes out of idle when a timer expires. In
> contrast, timers might or might not bring the system
> out of suspend, depending on both hardware capabilities
> and platform/application policy.
>
>
> CATEGORIES OF APPLICATION BEHAVIOR
>
> There are a number of categories of application behavior with respect
> to power management and energy efficiency. These can be classified via
> the following questions: (1) What degree of control is an application
> permitted over its own behavior? (2) What degree of control is an
> application permitted over the power state of individual devices within
> the system? (3) What degree of control is an application permitted
> over the system sleep state? (4) To what degree has the application
> been tuned to reduce its power consumption, either in isolation or in
> conjunction with other applications that might be running concurrently?
>
> These categories are discussed below.
>
> o What degree of control is an application permitted over its
> own behavior?
>
> The Linux kernel already has many controls over application
> behavior:
>
> o the CAP_ capabilities from include/linux/capability.h.
>
> o Processes can be assigned to multiple groups, allowing
> them privileged access to portions of the filesystem.
>
> o The chroot() system call limits a process's access to the
> specified subtree of the filesystem.
>
> o The ulimit facility can limit CPU consumption, number
> of processes, memory, etc. on a per-user basis. The
> rlimit facility has similar effects on a per-process
> basis.
>
> o The mlockall() system call provides privileged access
> to memory, avoiding page-fault overhead.
>
> But more relevant to this discussion, real-time processes are
> permitted a much higher degree of control over the timing of their
> execution than are non-real-time processes. However, suspending
> the system destroys any pretense of offering real-time guarantees,
> which might explain much of the annoyance towards suspend blockers
> from the real-time and scheduler folks. For but one example,
> Peter Zijlstra suggested that he would merge a patch that acquired
> a suspend blocker any time that the runqueues were non-empty.
> My first reaction was amusement at this vintage Peter Zijlstra
> response, and my second reaction was that it was a futile gesture,
> as the Android guys would simply back out any such change.
>
> After more thought, however, a variation of Peter's approach
> might well be the key to resolving this tension between
> real-time response on the one hand and Android's desire to
> conserve power at any cost on the other. Given that suspending
> destroys real-time response, why not acquire a suspend blocker
> any time there is a user-created real-time task in the system,
> whether runnable or not? Of course, a simpler approach would
> be to make Android's OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT.
>
> o What degree of control is an application permitted over the power
> state of individual devices within the system?
>
> Is the application in question permitted to power down the
> CPU or peripheral devices? As more of the power control is
> automated based on usage, it is possible that this question will
> become less relevant. The longer the latency and the greater
> the energy consumption of a power-up/power-down sequence for
> a given device, the less suitable that device is for automatic
> power-up/power-down decisions. Cache SRAMs and main-memory
> DRAM tend to be less suitable for automation for this reason.
>
> o What degree of control is an application permitted over the
> system sleep state?
>
> Is the application permitted to suspend the device? Or in the
> case of Android, is the application permitted to acquire a
> suspend blocker, which prevents the device from being suspended?
>
> o To what degree has the application been tuned to reduce its
> power consumption, either in isolation or in conjunction with
> other applications that might be running concurrently?
>
> See the "POWER-OPTIMIZED APPLICATIONS" section below for more
> detail on the lengths that embedded developers go to in order
> to conserve power -- or, more accurately, to extend battery life.
>
>
> REQUIREMENTS
>
> o Reduce the system's power consumption in order to (1) extend
> battery life and (2) preserve state until external power can
> be obtained.
>
> o It is necessary to be able to use power-oblivious 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 external power or
> (2) relatively undemanding laptop battery-lifetime expectations.
> The system must be capable of running these power-oblivious
> applications without requiring that these applications be
> modified, and must be capable of reasonable power efficiency
> even when power-oblivious applications are in use.
>
> In other words, it must be possible to automate the incorporation
> of a power-oblivious application into the Android environment,
> but without significantly degrading battery lifetime.
>
> 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 it is highly desirable that the
> application also be prevented from consuming power computing
> something that will not be displayed. Furthermore, whatever
> mechanism is used must operate on power-oblivious applications
> that do not use blocking system calls.
>
> There might well be similar requirements for other output-only
> devices, as noted by Alan Stern.
>
> o In order to avoid overrunning hardware and/or kernel buffers,
> and to minimize response latencies, designated 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 sleep state is received while the system is
> transitioning into a sleep state, the system must transition
> back out of the sleep state so that it can hand the user
> input off to the corresponding application.
>
> Other input events do not force a wakeup, and such input events
> -can- be lost due to buffer overflow in hardware or the kernel.
> The response latency to such input events can of course be
> unbounded.
>
> o Because Android acquires a suspend blocker as soon as an
> input event is noticed and holds it until some application
> reads that input event, there must be a way to cause the
> suspend blocker to timeout. If there was no such timeout
> facility, a power-oblivious application could block suspend by
> opening an input device and then refusing to ever read from it.
> (Yes, this can be considered to be a energy-efficiency bug in
> the power-oblivious application. Please see the statistics
> requirement below.)
>
> o The API must provide a way for PM-driving applications that
> receive events to keep themselves running until they have been
> able to process those events.
>
> o Statistics of the power-control actions taken by PM-driving
> applications must be provided. Statistics are aggregated by name,
> which is passed by the application in through the suspend-blocker
> interface. The following specific statistics are collected in
> the kernel, in roughly decreasing order of importance:
>
> o total_time, which accumulates the total amount of time
> that the corresponding suspend blocker has been held.
>
> o active_since, which tracks how long a suspend blocker has
> been held since it was last acquired, or (presumably) zero
> if it is not currently held.
>
> o count, which is the number of times that the suspend
> blocker has been acquired. This is useful in combination
> with total_time, as it allows you to calculate the
> average hold time for the suspend blocker.
>
> o expire_count, which is the number of times that the
> suspend blocker has timed out. This indicates that
> some application has an input device open, but is
> not reading from it, which is a bug, as noted earlier.
>
> o max_time, which is the longest hold time for the suspend
> blocker. This allows finding cases where suspend blockers
> are held for too long, but are eventually released.
> (In contrast, active_since is more useful in the
> held-forever case.)
>
> o sleep_time, which is the total time that the suspend
> blocker was held while the display was powered off.
> (This might have interesting implications should E-ink
> displays every become capable of full-motion color video,
> but it is easy to imagine that the definition of "powered
> off" would then include only those times during which
> the display wasn't actively being updated.)
>
> o wake_count, which is the number of times that the
> suspend blocker was the first to be acquired in the
> resume path. This is less than useful on some
> Android platforms; Arve is dissatisfied with it
> on Nexus One.
>
> Presumably, the userspace code collects similar statistics on
> application suspend-blocker activity, but that is out of the scope
> of this document, which focuses instead on kernel requirements.
> Given that the overhead of maintaining these statistics is
> quite low, it seems that it would be worthwhile to have them
> enabled in production systems, for example, in order to flag
> power-buggy applications that the user has naively downloaded.
>
> o Some PM-driving applications use power-oblivious infrastructure
> code. This means that a PM-driving application must have
> some way, whether explicit or implicit, to ensure that any
> power-oblivious infrastructure code is permitted to run when a
> PM-driving application needs it to run.
>
> o If no PM-driving or power-optimized application are indicating
> a need for the system to remain operating, the system is permitted
> (even encouraged!) to suspend all execution, regardless of the
> state of power-oblivious applications. (This requirement did
> appear to be somewhat controversial, both in terms of what is
> meant by "runnable" and in terms of what constitutes "execution".)
>
> In Android, this is implemented by suspending even while
> PM-driving or power-optimized applications are active, -unless-
> a suspend blocker is held.
>
> o Transition to system sleep state must be power-efficient.
> In particular, methods based on repeated attempts to suspend
> are considered to be too inefficient to be useful.
>
> o Transition to system sleep state must occur very soon after
> all PM-driving and power-optimized applications have indicated
> that they have no need for the system to remain operating.
> Quick transition is expecially important in cases where the wakeup
> was momentary, for example, when processing sporadic network
> input or processing widely spaced batches of audio output.
> For an example of the latter, MP3 playback allows 1-4 minute
> spacing between bursts of CPU activity).
>
> 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 sleep 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 The API that controls the system sleep 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 sleep 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. According to Brian
> Swetland:
>
> For Java/Dalvik apps, the wakelock API is pertty
> high level -- it talks to a service via RPC (Binder)
> that actually interacts with the kernel. Changing the
> basic kernel<->userspace interface (within reason) is
> not unthinkable. For example, Arve's suspend_blocker
> patch provides a device interface rather than the proc
> interface the older wakelock patches use. We'd have to
> make some userspace changes to support that but they're
> pretty low level and minor.
>
> In the current model, only a few processes need to
> specifically interact with the kernel (the power
> management service in the system_server, possibly the
> media_server and the radio interface glue). A model where
> every process needs to have a bunch of instrumentation is
> not very desirable from our point of view. We definitely
> do need reasonable statistics in order to enable debugging
> and to enable reporting to endusers (through the Battery
> Usage UI) what's keeping the device awake.
>
> o Any mechanism that freezes some subset of the applications must
> ensure that none of the frozen applications hold any user-level
> resources, such as pthread mutexes. The reason for this is that
> freezing an application that holds a shared pthread mutex will
> result in an application-level hang should some unfrozen process
> attempt to acquire that same pthread mutex. Note that although
> the current cgroup freezer ensures that frozen applications do not
> hold any kernel-level mutexes (at least assuming these mutexes
> are not wrongly held when returning to user-level execution),
> it currently does nothing to prevent freezing processes holding
> pthread mutexes. (There are some proposals to address this issue.)
>
>
> NICE-TO-HAVES
>
> o It would be nice to be able to identify power-oblivious
> applications that never were depended on by PM-driving
> applications. This particular class of power-oblivious
> applications could be shut down when the screen blanks even
> if some PM-driving application was preventing the system from
> powering down.
>
> There are two obstacles to meeting this requirement:
>
> 1. There must be a reliable way to identify such
> applications. This should be doable, for example, the
> application might be tagged by its developer.
>
> 2. There must be a reliable way to freeze them such
> that no frozen application holds a resource that
> might be contended by a non-frozen application.
>
> Although the cgroup freezer does ensure that frozen
> tasks hold no kernel-level resources, it currently does
> nothing to ensure that no user-level resources are held.
> There are some alternative proposals, which might or
> might not be more successful:
>
> a. Unfreeze this group periodically to ensure
> that any such resource is eventually released,
> while keeping power consumption down to a dull
> roar.
>
> b. Perform the freeze at application level, where
> it is possible to determine whether an
> application-level resource is held.
>
> o Any initialization of the API that controls the system power
> state should be unconditional, so as to be free from failure.
> Such unconditional initialization reduces the intrusiveness of
> the Android patchset.
>
>
> APPARENT NON-REQUIREMENTS
>
> o Transitioning to system sleep states need not be highly scalable,
> as evidenced by the global locks. (If you believe that high
> scalability 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.)
>
> That said, it should not be hard to provide a highly scalable
> implementation of suspend blockers, especially if large systems
> are allowed to take their time suspending themselves.
>
> o Conserving power in the WiFi and cellular telephony networks.
> At the moment, the focus is on increased battery life in the
> handheld device, perhaps even at the expense of additional
> power consumed by the externally powered WiFi and cell-telephony
> equipment.
>
> o Synchronizing wakeups of unrelated applications. This is of
> course an important requirement for power savings overall, but
> seems to be left to other mechanisms (e.g., timer aggregation)
> by the Android folks. Although one could implement suspend
> blockers so as to aggregate timers after a sufficiently long
> suspension, there are problems with this approach:
>
> o There would be a "thundering herd" problem just after
> resume completed as almost every timer in the system
> would expire simultaneously.
>
> o The applications would not necessarily stay aggregated
> without some other mechanism helping out.
>
>
> SUGGESTED USAGE
>
> These are constraints that the developer is expected to abide by,
> "for best results" and all that.
>
> o When a PM-driving application is preventing the system from
> shutting down, and is also waiting on a power-oblivious
> application, the PM-driving application should set a timeout
> to handle the possibility that the power-oblivious application
> might halt or otherwise fail.
>
>
> 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 sleep 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 achieve 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. Provide "heartbeat" services that allow applications to
> synchronize with each other. This seems most applicable for
> applications that run infrequently, such as email-checking and
> location-service applications.
>
> 5. 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.
>
> 6. 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 PM-driving (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-oblivious 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.
>
>
> ACKNOWLEDGMENTS
>
> Of course, just because I acknowledge their contributions does
> not necessarily mean that I think they agree with my assessment
> of the requirements behind suspend blockers. ;-)
>
> Nevertheless, I am grateful for any and all feedback, whatever
> the form of that feedback might be. I am new to this area, and
> have much to learn.
>
> Alan Stern
> Anca Emanuel
> Arjan van de Ven
> Arve Hj?nnev?g
> Brian Swetland
> David Brownell
> David Lang
> Florian Mickler
> James Bottomley
> Kevin Granade
> Mark Brown
> Matt Helsley
> Matthew Garrett
> Mikael Abrahamsson
> Olivier Galibert
> Paul Menage
> Pavel Machek
> Rafael J. Wysocki
> Richard Woodruff
> Ted Ts'o
>
On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
Guys, please try to cut unneeded text from the quotes - it makes it much
easier to find the new text.
>>> Well, not really from the Linux point of view. It's not massively
>>> different to something like keeping an ethernet controller sufficiently
>>> alive to allow it to provide wake on LAN functionality while the system
>> The wake-on-LAN and the lights-out management systems are indeed
>> interesting examples, and actually pretty good ones. The reason I
>> excluded them is that they don't do any application processing -- their
>> only purpose is the care and feeding of the system itself. In contrast,
>> the embedded processors are able to do significant applications processing
>> (e.g., play back music) while any CPUs are completely shut down and most
>> of the memory is powered down as well.
This isn't a particularly meaningful distinction, things like the LoM
systems on servers are generally at least as capable as things like the
DSPs doing tasks like offloaded MP3 decode and often provide useful
services in themselves (like system monitoring). It's really just
semantics to treat them differently to something like a cellular modem -
at a high level they're both just independant processors ticking away
without the application processor.
> one other significant issue is that on the PC, things like wake-on-LAN,
> lights out management cards, etc require nothing from the main system
> other than power. If they do something, they are sending the signal to
> the chipset, which then wakes the system up. they don't interact with the
> main processor/memory/etc at all.
I don't see that it makes much difference what gets kept alive - at the
end of the day the point is that we're making a decision to keep bits of
the system alive over suspend.
> So as I see it, we need to do one of two things.
> 1. change the suspend definition to allow for some things to not be
> suspended
This is essentially what's already happening.
> 2. change the sleep/low-power mode definition to have a more standardized
> way of turning things off, and extend it to allow clocks to be turned off
> as well (today we have things able to be turned off, drive spin-down for
> example, but per comments in this thread it's all one-off methods)
Currently things like clock trees are frequently managed orthogonaly to
the system power state to at least some extent anyway - for example,
perfectly normal wake events like button presses will often require
clocks for things like debouncing.
On Fri, Aug 06, 2010 at 04:59:54PM -0700, [email protected] wrote:
> one other nice-to-have (or conflicting requirement, depending on
> your point of view), and I think one of the big things causing
> people to dislike wavelocks, is the desire to not have to modify
> applications to have them work with the infrastructure.
>
> you sort of touch on this when you say that power oblivious
> applications need to be able to be intergrated, but it goes beyond
> what that statement implies.
>
> with wavelocka, even power optimized applications need to be
> modified, or the system may halt them at any time.
Yes, I believe that Android would require most power-optimized application
be modified to use wakelocks. But power-optimized applications require
so much tweaking that the addition of suspend blockers (or whatever
other power-control mechanism) is pretty much a non-issue by comparison.
And the number of power-optimized applications should be small, which,
as you noted earlier, greatly eases the overall pain of modifying them.
> one thing that has been very clear over the years is that if an API
> only exists on Linux, no matter how good it is, most application
> developers won't use it.
Many application developers do indeed value portability. But this in turn
means that most application developers will not be writing power-optimized
applications, because the process of power-optimization significantly
degrades portability. Just as does the process of performance tuning,
beyond a certain point.
Of course, the reason that application developers value portability is
that this is one way to gain large unit volumes. Another way to gain
large unit volumes is to code for a very popular platform, which explains
the large number of apps that run only on iPhone, Android, and Windows.
And in my experience, developers who have decided to commit to a single
platform are usually not at all shy about exploiting special facilities
of that platform to the fullest.
> In this case we are in an even worse situation, it's not only
> specific to Linux, it's specific to a subset of Linux systems, and
> not using it will cause no problems most of the time.
It seems to me that PM-driving and power-optimized applications are going
to be highly platform specific, whether that platform be Linux or some
other OS.
> now, android is betting that the apps are all developed specifically
> for the android from scratch, so having a different API is
> acceptable, even if it cuts them off from the rest of the *nix
> applications. For a phone this is not neccessarily an unreasonable
> stance, but as Android moves into the spaces where normal
> applications are in use (netbooks and tablets), this becomes a much
> shakier stance to take.
There certainly does seem to be a large and growing number of Android
apps, so I might be reluctant to bet against them. And the Android guys
appear to be making another bet as well -- that almost all applications
will be power-oblivious. Their design handles this rather well, given
that such applications need not worry about special power-control
features.
Thanx, Paul
> David Lang
>
> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
>
> >Date: Fri, 6 Aug 2010 15:54:53 -0700
> >From: Paul E. McKenney <[email protected]>
> >To: [email protected], [email protected]
> >Cc: [email protected], [email protected], [email protected], [email protected],
> > [email protected], [email protected], [email protected],
> > [email protected], [email protected], [email protected],
> > [email protected], [email protected], [email protected],
> > [email protected], [email protected], [email protected],
> > [email protected], [email protected], [email protected]
> >Subject: Attempted summary of suspend-blockers LKML thread, take three
> >
> >Final report from this particular angel-free zone for the time being...
> >
> >This is the third and final version of my Android requirements list
> >(last version available at http://lkml.org/lkml/2010/8/4/409). Again,
> >this email is an attempt to present the Android guys' requirements, based
> >on my interpretation of LKML discussions. This past week's discussion
> >was quite productive, and I thank everyone who took part.
> >
> >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 our collective understanding of what the Android
> >folks' requirements are. That said, I do discuss example mechanisms
> >where needed to clarify the meaning of the requirements. This should
> >not be interpreted as a preference for any given example mechanism.
> >
> > Thanx, Paul
> >
> >------------------------------------------------------------------------
> >
> >CONTENTS
> >
> >o DEFINITIONS
> >o CATEGORIES OF APPLICATION BEHAVIOR
> >o REQUIREMENTS
> >o NICE-TO-HAVES
> >o APPARENT NON-REQUIREMENTS
> >o SUGGESTED USAGE
> >o POWER-OPTIMIZED APPLICATIONS
> >o OTHER EXAMPLE APPLICATIONS
> >o ACKNOWLEDGMENTS
> >
> >
> >DEFINITIONS
> >
> >These have been updated based on LKML and linux-pm discussions. The names
> >are probably still sub-optimal, but incremental progress is nevertheless
> >a very good thing.
> >
> >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
> > externally powered PCs. Many other people seemed to instead be
> > thinking in terms of an ill-conceived or useless application,
> > perhaps exemplified by "bouncing cows".
> >
> > This document uses "power-oblivious applications" to mean
> > applications that are well-designed and well-implemented in in
> > general, but which do not take power consumption or battery life
> > into account.
> >
> >o "PM-driving 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 processes are classified as power aware. Android uses a
> > user-level daemon to classify app-store apps as PM-driving or not.
> > More generally, PM-driving applications are those that have
> > permission to exert some control over the system's sleep state.
> >
> > Note that an application might be power-oblivious on one
> > Android device and PM-driving on another, depending on whether
> > the user allows that application to acquire suspend blockers.
> > The classification might even change over time. For example,
> > a user might give an application PM-driving status initially,
> > but change his or her mind after some experience with that
> > application.
> >
> >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
> > PM-driving applications that have been aggressively tuned to
> > reduce power consumption.
> >
> >o Individual devices in an embedded system can enter "device
> > low-power states" when not in use.
> >
> >o The system as a whole can enter a "system sleep state" when
> > the system as a whole is not in use. Suspend blockers are about
> > system sleep states rather than device low-power states.
> >
> >o There was much discussion of "idle" (AKA "deep idle") and
> > "suspend" (as in current Linux-kernel suspend operations).
> > The following characteristics distinguish "idle" from "suspend":
> >
> > 1. Idle states are entered by a given CPU only there are no
> > runnable tasks for that CPU. In contrast, opportunistic
> > suspend can halt the entire system even when there
> > are tasks that are ready, willing, and able to run.
> > (But please note that this might not apply to real-time
> > tasks.)
> >
> > Freezing of subsets of applications is somewhat related
> > to the idle/suspend discussion, but is covered in a
> > later section of this document.
> >
> > 2. There can be a set of input events that do not bring
> > the system out of suspend, but which would bring the
> > system out of idle. Exactly which events are in this
> > set depends both on hardware capabilities and on the
> > platform/application policy. For example, on one of
> > the Android-based smartphones, touchscreen input is
> > ignored when the system is suspended, but is handled
> > when idle.
> >
> > 3. The system comes out of idle when a timer expires. In
> > contrast, timers might or might not bring the system
> > out of suspend, depending on both hardware capabilities
> > and platform/application policy.
> >
> >
> >CATEGORIES OF APPLICATION BEHAVIOR
> >
> >There are a number of categories of application behavior with respect
> >to power management and energy efficiency. These can be classified via
> >the following questions: (1) What degree of control is an application
> >permitted over its own behavior? (2) What degree of control is an
> >application permitted over the power state of individual devices within
> >the system? (3) What degree of control is an application permitted
> >over the system sleep state? (4) To what degree has the application
> >been tuned to reduce its power consumption, either in isolation or in
> >conjunction with other applications that might be running concurrently?
> >
> >These categories are discussed below.
> >
> >o What degree of control is an application permitted over its
> > own behavior?
> >
> > The Linux kernel already has many controls over application
> > behavior:
> >
> > o the CAP_ capabilities from include/linux/capability.h.
> >
> > o Processes can be assigned to multiple groups, allowing
> > them privileged access to portions of the filesystem.
> >
> > o The chroot() system call limits a process's access to the
> > specified subtree of the filesystem.
> >
> > o The ulimit facility can limit CPU consumption, number
> > of processes, memory, etc. on a per-user basis. The
> > rlimit facility has similar effects on a per-process
> > basis.
> >
> > o The mlockall() system call provides privileged access
> > to memory, avoiding page-fault overhead.
> >
> > But more relevant to this discussion, real-time processes are
> > permitted a much higher degree of control over the timing of their
> > execution than are non-real-time processes. However, suspending
> > the system destroys any pretense of offering real-time guarantees,
> > which might explain much of the annoyance towards suspend blockers
> > from the real-time and scheduler folks. For but one example,
> > Peter Zijlstra suggested that he would merge a patch that acquired
> > a suspend blocker any time that the runqueues were non-empty.
> > My first reaction was amusement at this vintage Peter Zijlstra
> > response, and my second reaction was that it was a futile gesture,
> > as the Android guys would simply back out any such change.
> >
> > After more thought, however, a variation of Peter's approach
> > might well be the key to resolving this tension between
> > real-time response on the one hand and Android's desire to
> > conserve power at any cost on the other. Given that suspending
> > destroys real-time response, why not acquire a suspend blocker
> > any time there is a user-created real-time task in the system,
> > whether runnable or not? Of course, a simpler approach would
> > be to make Android's OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT.
> >
> >o What degree of control is an application permitted over the power
> > state of individual devices within the system?
> >
> > Is the application in question permitted to power down the
> > CPU or peripheral devices? As more of the power control is
> > automated based on usage, it is possible that this question will
> > become less relevant. The longer the latency and the greater
> > the energy consumption of a power-up/power-down sequence for
> > a given device, the less suitable that device is for automatic
> > power-up/power-down decisions. Cache SRAMs and main-memory
> > DRAM tend to be less suitable for automation for this reason.
> >
> >o What degree of control is an application permitted over the
> > system sleep state?
> >
> > Is the application permitted to suspend the device? Or in the
> > case of Android, is the application permitted to acquire a
> > suspend blocker, which prevents the device from being suspended?
> >
> >o To what degree has the application been tuned to reduce its
> > power consumption, either in isolation or in conjunction with
> > other applications that might be running concurrently?
> >
> > See the "POWER-OPTIMIZED APPLICATIONS" section below for more
> > detail on the lengths that embedded developers go to in order
> > to conserve power -- or, more accurately, to extend battery life.
> >
> >
> >REQUIREMENTS
> >
> >o Reduce the system's power consumption in order to (1) extend
> > battery life and (2) preserve state until external power can
> > be obtained.
> >
> >o It is necessary to be able to use power-oblivious 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 external power or
> > (2) relatively undemanding laptop battery-lifetime expectations.
> > The system must be capable of running these power-oblivious
> > applications without requiring that these applications be
> > modified, and must be capable of reasonable power efficiency
> > even when power-oblivious applications are in use.
> >
> > In other words, it must be possible to automate the incorporation
> > of a power-oblivious application into the Android environment,
> > but without significantly degrading battery lifetime.
> >
> >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 it is highly desirable that the
> > application also be prevented from consuming power computing
> > something that will not be displayed. Furthermore, whatever
> > mechanism is used must operate on power-oblivious applications
> > that do not use blocking system calls.
> >
> > There might well be similar requirements for other output-only
> > devices, as noted by Alan Stern.
> >
> >o In order to avoid overrunning hardware and/or kernel buffers,
> > and to minimize response latencies, designated 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 sleep state is received while the system is
> > transitioning into a sleep state, the system must transition
> > back out of the sleep state so that it can hand the user
> > input off to the corresponding application.
> >
> > Other input events do not force a wakeup, and such input events
> > -can- be lost due to buffer overflow in hardware or the kernel.
> > The response latency to such input events can of course be
> > unbounded.
> >
> >o Because Android acquires a suspend blocker as soon as an
> > input event is noticed and holds it until some application
> > reads that input event, there must be a way to cause the
> > suspend blocker to timeout. If there was no such timeout
> > facility, a power-oblivious application could block suspend by
> > opening an input device and then refusing to ever read from it.
> > (Yes, this can be considered to be a energy-efficiency bug in
> > the power-oblivious application. Please see the statistics
> > requirement below.)
> >
> >o The API must provide a way for PM-driving applications that
> > receive events to keep themselves running until they have been
> > able to process those events.
> >
> >o Statistics of the power-control actions taken by PM-driving
> > applications must be provided. Statistics are aggregated by name,
> > which is passed by the application in through the suspend-blocker
> > interface. The following specific statistics are collected in
> > the kernel, in roughly decreasing order of importance:
> >
> > o total_time, which accumulates the total amount of time
> > that the corresponding suspend blocker has been held.
> >
> > o active_since, which tracks how long a suspend blocker has
> > been held since it was last acquired, or (presumably) zero
> > if it is not currently held.
> >
> > o count, which is the number of times that the suspend
> > blocker has been acquired. This is useful in combination
> > with total_time, as it allows you to calculate the
> > average hold time for the suspend blocker.
> >
> > o expire_count, which is the number of times that the
> > suspend blocker has timed out. This indicates that
> > some application has an input device open, but is
> > not reading from it, which is a bug, as noted earlier.
> >
> > o max_time, which is the longest hold time for the suspend
> > blocker. This allows finding cases where suspend blockers
> > are held for too long, but are eventually released.
> > (In contrast, active_since is more useful in the
> > held-forever case.)
> >
> > o sleep_time, which is the total time that the suspend
> > blocker was held while the display was powered off.
> > (This might have interesting implications should E-ink
> > displays every become capable of full-motion color video,
> > but it is easy to imagine that the definition of "powered
> > off" would then include only those times during which
> > the display wasn't actively being updated.)
> >
> > o wake_count, which is the number of times that the
> > suspend blocker was the first to be acquired in the
> > resume path. This is less than useful on some
> > Android platforms; Arve is dissatisfied with it
> > on Nexus One.
> >
> > Presumably, the userspace code collects similar statistics on
> > application suspend-blocker activity, but that is out of the scope
> > of this document, which focuses instead on kernel requirements.
> > Given that the overhead of maintaining these statistics is
> > quite low, it seems that it would be worthwhile to have them
> > enabled in production systems, for example, in order to flag
> > power-buggy applications that the user has naively downloaded.
> >
> >o Some PM-driving applications use power-oblivious infrastructure
> > code. This means that a PM-driving application must have
> > some way, whether explicit or implicit, to ensure that any
> > power-oblivious infrastructure code is permitted to run when a
> > PM-driving application needs it to run.
> >
> >o If no PM-driving or power-optimized application are indicating
> > a need for the system to remain operating, the system is permitted
> > (even encouraged!) to suspend all execution, regardless of the
> > state of power-oblivious applications. (This requirement did
> > appear to be somewhat controversial, both in terms of what is
> > meant by "runnable" and in terms of what constitutes "execution".)
> >
> > In Android, this is implemented by suspending even while
> > PM-driving or power-optimized applications are active, -unless-
> > a suspend blocker is held.
> >
> >o Transition to system sleep state must be power-efficient.
> > In particular, methods based on repeated attempts to suspend
> > are considered to be too inefficient to be useful.
> >
> >o Transition to system sleep state must occur very soon after
> > all PM-driving and power-optimized applications have indicated
> > that they have no need for the system to remain operating.
> > Quick transition is expecially important in cases where the wakeup
> > was momentary, for example, when processing sporadic network
> > input or processing widely spaced batches of audio output.
> > For an example of the latter, MP3 playback allows 1-4 minute
> > spacing between bursts of CPU activity).
> >
> >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 sleep 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 The API that controls the system sleep 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 sleep 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. According to Brian
> > Swetland:
> >
> > For Java/Dalvik apps, the wakelock API is pertty
> > high level -- it talks to a service via RPC (Binder)
> > that actually interacts with the kernel. Changing the
> > basic kernel<->userspace interface (within reason) is
> > not unthinkable. For example, Arve's suspend_blocker
> > patch provides a device interface rather than the proc
> > interface the older wakelock patches use. We'd have to
> > make some userspace changes to support that but they're
> > pretty low level and minor.
> >
> > In the current model, only a few processes need to
> > specifically interact with the kernel (the power
> > management service in the system_server, possibly the
> > media_server and the radio interface glue). A model where
> > every process needs to have a bunch of instrumentation is
> > not very desirable from our point of view. We definitely
> > do need reasonable statistics in order to enable debugging
> > and to enable reporting to endusers (through the Battery
> > Usage UI) what's keeping the device awake.
> >
> >o Any mechanism that freezes some subset of the applications must
> > ensure that none of the frozen applications hold any user-level
> > resources, such as pthread mutexes. The reason for this is that
> > freezing an application that holds a shared pthread mutex will
> > result in an application-level hang should some unfrozen process
> > attempt to acquire that same pthread mutex. Note that although
> > the current cgroup freezer ensures that frozen applications do not
> > hold any kernel-level mutexes (at least assuming these mutexes
> > are not wrongly held when returning to user-level execution),
> > it currently does nothing to prevent freezing processes holding
> > pthread mutexes. (There are some proposals to address this issue.)
> >
> >
> >NICE-TO-HAVES
> >
> >o It would be nice to be able to identify power-oblivious
> > applications that never were depended on by PM-driving
> > applications. This particular class of power-oblivious
> > applications could be shut down when the screen blanks even
> > if some PM-driving application was preventing the system from
> > powering down.
> >
> > There are two obstacles to meeting this requirement:
> >
> > 1. There must be a reliable way to identify such
> > applications. This should be doable, for example, the
> > application might be tagged by its developer.
> >
> > 2. There must be a reliable way to freeze them such
> > that no frozen application holds a resource that
> > might be contended by a non-frozen application.
> >
> > Although the cgroup freezer does ensure that frozen
> > tasks hold no kernel-level resources, it currently does
> > nothing to ensure that no user-level resources are held.
> > There are some alternative proposals, which might or
> > might not be more successful:
> >
> > a. Unfreeze this group periodically to ensure
> > that any such resource is eventually released,
> > while keeping power consumption down to a dull
> > roar.
> >
> > b. Perform the freeze at application level, where
> > it is possible to determine whether an
> > application-level resource is held.
> >
> >o Any initialization of the API that controls the system power
> > state should be unconditional, so as to be free from failure.
> > Such unconditional initialization reduces the intrusiveness of
> > the Android patchset.
> >
> >
> >APPARENT NON-REQUIREMENTS
> >
> >o Transitioning to system sleep states need not be highly scalable,
> > as evidenced by the global locks. (If you believe that high
> > scalability 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.)
> >
> > That said, it should not be hard to provide a highly scalable
> > implementation of suspend blockers, especially if large systems
> > are allowed to take their time suspending themselves.
> >
> >o Conserving power in the WiFi and cellular telephony networks.
> > At the moment, the focus is on increased battery life in the
> > handheld device, perhaps even at the expense of additional
> > power consumed by the externally powered WiFi and cell-telephony
> > equipment.
> >
> >o Synchronizing wakeups of unrelated applications. This is of
> > course an important requirement for power savings overall, but
> > seems to be left to other mechanisms (e.g., timer aggregation)
> > by the Android folks. Although one could implement suspend
> > blockers so as to aggregate timers after a sufficiently long
> > suspension, there are problems with this approach:
> >
> > o There would be a "thundering herd" problem just after
> > resume completed as almost every timer in the system
> > would expire simultaneously.
> >
> > o The applications would not necessarily stay aggregated
> > without some other mechanism helping out.
> >
> >
> >SUGGESTED USAGE
> >
> >These are constraints that the developer is expected to abide by,
> >"for best results" and all that.
> >
> >o When a PM-driving application is preventing the system from
> > shutting down, and is also waiting on a power-oblivious
> > application, the PM-driving application should set a timeout
> > to handle the possibility that the power-oblivious application
> > might halt or otherwise fail.
> >
> >
> >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 sleep 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 achieve 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. Provide "heartbeat" services that allow applications to
> > synchronize with each other. This seems most applicable for
> > applications that run infrequently, such as email-checking and
> > location-service applications.
> >
> >5. 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.
> >
> >6. 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 PM-driving (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-oblivious 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.
> >
> >
> >ACKNOWLEDGMENTS
> >
> > Of course, just because I acknowledge their contributions does
> > not necessarily mean that I think they agree with my assessment
> > of the requirements behind suspend blockers. ;-)
> >
> > Nevertheless, I am grateful for any and all feedback, whatever
> > the form of that feedback might be. I am new to this area, and
> > have much to learn.
> >
> > Alan Stern
> > Anca Emanuel
> > Arjan van de Ven
> > Arve Hj?nnev?g
> > Brian Swetland
> > David Brownell
> > David Lang
> > Florian Mickler
> > James Bottomley
> > Kevin Granade
> > Mark Brown
> > Matt Helsley
> > Matthew Garrett
> > Mikael Abrahamsson
> > Olivier Galibert
> > Paul Menage
> > Pavel Machek
> > Rafael J. Wysocki
> > Richard Woodruff
> > Ted Ts'o
> >
On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
> > On Fri, 6 Aug 2010, Paul E. McKenney wrote:
>
> Guys, please try to cut unneeded text from the quotes - it makes it much
> easier to find the new text.
>
> >>> Well, not really from the Linux point of view. It's not massively
> >>> different to something like keeping an ethernet controller sufficiently
> >>> alive to allow it to provide wake on LAN functionality while the system
>
> >> The wake-on-LAN and the lights-out management systems are indeed
> >> interesting examples, and actually pretty good ones. The reason I
> >> excluded them is that they don't do any application processing -- their
> >> only purpose is the care and feeding of the system itself. In contrast,
> >> the embedded processors are able to do significant applications processing
> >> (e.g., play back music) while any CPUs are completely shut down and most
> >> of the memory is powered down as well.
>
> This isn't a particularly meaningful distinction, things like the LoM
> systems on servers are generally at least as capable as things like the
> DSPs doing tasks like offloaded MP3 decode and often provide useful
> services in themselves (like system monitoring). It's really just
> semantics to treat them differently to something like a cellular modem -
> at a high level they're both just independant processors ticking away
> without the application processor.
I agree that a smartphone's cellular modem can be argued to be very
similar to wake-on-LAN. The smartphone applications that seem to me
to be very different from wake-on-LAN are things like audio playback,
where the system is providing service to the user during the time that
it is suspended.
> > one other significant issue is that on the PC, things like wake-on-LAN,
> > lights out management cards, etc require nothing from the main system
> > other than power. If they do something, they are sending the signal to
> > the chipset, which then wakes the system up. they don't interact with the
> > main processor/memory/etc at all.
>
> I don't see that it makes much difference what gets kept alive - at the
> end of the day the point is that we're making a decision to keep bits of
> the system alive over suspend.
The distinction is whether or not the system is perceived to be actively
doing something useful while it is suspended. Yes, this is subjective,
but the distinction is still important.
> > So as I see it, we need to do one of two things.
>
> > 1. change the suspend definition to allow for some things to not be
> > suspended
>
> This is essentially what's already happening.
The time-of-day clock is certainly a case in point here. ;-)
Thanx, Paul
> > 2. change the sleep/low-power mode definition to have a more standardized
> > way of turning things off, and extend it to allow clocks to be turned off
> > as well (today we have things able to be turned off, drive spin-down for
> > example, but per comments in this thread it's all one-off methods)
>
> Currently things like clock trees are frequently managed orthogonaly to
> the system power state to at least some extent anyway - for example,
> perfectly normal wake events like button presses will often require
> clocks for things like debouncing.
On Sat, 7 Aug 2010, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
>> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
>
>> So as I see it, we need to do one of two things.
>
>> 1. change the suspend definition to allow for some things to not be
>> suspended
>
> This is essentially what's already happening.
>
>> 2. change the sleep/low-power mode definition to have a more standardized
>> way of turning things off, and extend it to allow clocks to be turned off
>> as well (today we have things able to be turned off, drive spin-down for
>> example, but per comments in this thread it's all one-off methods)
>
> Currently things like clock trees are frequently managed orthogonaly to
> the system power state to at least some extent anyway - for example,
> perfectly normal wake events like button presses will often require
> clocks for things like debouncing.
I recognise that #1 is essentially what Android is already doing.
I'm asking the question, "Is this what Linux should be doing?
Personally, I think that suspend should be treated much more like a
low-power state and much less like hibernation than it currently is (I
believe that Linus has also voiced this opinion). And I think that the
situation with Android suspending while audio is playing between busts of
CPU activity is a perfect example.
for the moment, forget the problem of other apps that may be running, and
consider a system that's just running a media player.
the media player needs bursts of CPU to decode the media so that the
output device can access it (via DMA or something like that)
the media player needs bursts of I/O to read the encoded program source
from storage.
What we want to have happen in an ideal world is
when the storage isn't needed (between reads) the storage should shutdown
to as low a power state as possible.
when the CPU isn't needed (between decoding bursts) the CPU and as much of
the system as possible (potentially including some banks of RAM) should
shutdown to as low a power state as possible.
today there are two ways of this happening, via the idle approach (on
everything except Android), or via suspend (on Android)
Given that many platforms cannot go to into suspend while still playing
audio, the idle approach is not going to be able to be eliminated (and in
fact will be the most common approach to be used/deugged in terms of the
types of platforms), it seems to me that there may be a significant amount
of value in seeing if there is a way to change Android to use this
approach as well instead of having two different systems competing to do
the same job.
David Lang
On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> On Fri, Aug 06, 2010 at 04:59:54PM -0700, [email protected] wrote:
>> one other nice-to-have (or conflicting requirement, depending on
>> your point of view), and I think one of the big things causing
>> people to dislike wavelocks, is the desire to not have to modify
>> applications to have them work with the infrastructure.
>>
>> you sort of touch on this when you say that power oblivious
>> applications need to be able to be intergrated, but it goes beyond
>> what that statement implies.
>>
>> with wavelocka, even power optimized applications need to be
>> modified, or the system may halt them at any time.
>
> Yes, I believe that Android would require most power-optimized application
> be modified to use wakelocks. But power-optimized applications require
> so much tweaking that the addition of suspend blockers (or whatever
> other power-control mechanism) is pretty much a non-issue by comparison.
>
> And the number of power-optimized applications should be small, which,
> as you noted earlier, greatly eases the overall pain of modifying them.
except, power optimized applications aren't just written for android, they
are also written for many other battery powered devices, many of which
don't use wavelocks (and in fact, have no real reason to as they don't
also have the untrusted apps running)
As such the pool of power optmized software will grow faster than the pool
of wakelock enabled software.
>> one thing that has been very clear over the years is that if an API
>> only exists on Linux, no matter how good it is, most application
>> developers won't use it.
>
> Many application developers do indeed value portability. But this in turn
> means that most application developers will not be writing power-optimized
> applications, because the process of power-optimization significantly
> degrades portability. Just as does the process of performance tuning,
> beyond a certain point.
just like performance tuning, power optimization only degrades portability
beyond a certin point. A lot of power optimization is like a lot of
performance tuning, find algorithms that you are using (usually frequent
polling in the case of power optimizations) and change them. These changes
are very frequently very portable.
In this case we are talking about changes that not only aren't portable
across different Operating systems, they would not even be portable across
Linux itself.
> Of course, the reason that application developers value portability is
> that this is one way to gain large unit volumes. Another way to gain
> large unit volumes is to code for a very popular platform, which explains
> the large number of apps that run only on iPhone, Android, and Windows.
>
> And in my experience, developers who have decided to commit to a single
> platform are usually not at all shy about exploiting special facilities
> of that platform to the fullest.
and they are not shy about ignoring other variations of a platform either
(for example, Adobe has flash for i386 linux, but not amd64 linux, arm
linux, powerpc linux, etc)
I see this as a bad thing to be discouraged.
>> In this case we are in an even worse situation, it's not only
>> specific to Linux, it's specific to a subset of Linux systems, and
>> not using it will cause no problems most of the time.
>
> It seems to me that PM-driving and power-optimized applications are going
> to be highly platform specific, whether that platform be Linux or some
> other OS.
The thing is, they don't need to be.
>> now, android is betting that the apps are all developed specifically
>> for the android from scratch, so having a different API is
>> acceptable, even if it cuts them off from the rest of the *nix
>> applications. For a phone this is not neccessarily an unreasonable
>> stance, but as Android moves into the spaces where normal
>> applications are in use (netbooks and tablets), this becomes a much
>> shakier stance to take.
>
> There certainly does seem to be a large and growing number of Android
> apps, so I might be reluctant to bet against them. And the Android guys
> appear to be making another bet as well -- that almost all applications
> will be power-oblivious. Their design handles this rather well, given
> that such applications need not worry about special power-control
> features.
there is also a growing population of nook applications, kindle
applications (ok, in this category there are only two released, both in
the last week, but the SDK has not hit public release yet ;-), maemo
applications, OLPC applications, tom-tom applications, .....
unless all of these platforms are going to start using wavelocks there are
going to be power optimized applications out there that don't use
wavelocks.
>From this discussion, it looks to me like Android wants two key features
that they don't see a way to get today
1. the ability to decide to suspend while there are still some
'unimportant' apps running.
2. changes to idle/suspend so that they can get into a state of lower
power consumption thatn any existing idle state (by being able to disable
clocks), but still have some parts of the system powered (so that they are
more awake than suspend)
If these two features were available, I think that the rest of what they
are looking for could be built up without requireing other changes.
In addition to these key features, the fact that they use suspend much
more frequently means that the race condition between deciding to freeze
and wake events happening is far more likely to cause them problems, so
improvements in this area are needed. I don't think that there is any
fundamental opposition to these improvements, just questions on how best
to do it without causing performance problems.
Today Android uses wakelocks to indicate that there is something
'important' running and trigger a suspend when nothing 'important' is
running.
they have cusomized suspend to sometimes not shut everythng down.
My straw-man to address these is the following
1. create the ability to tag cgroups with power management values
track their timers separatly
be able to set idle time before sleep per-group instead of system-wide
other things in the future
eventually this could be things like preventing processes in
different cgroups from sharing userspace mutexes (or at least detecting
when this is the case) to support being able to freeze one cgroup without
affectng others.
2. modify the schedular/idle thread to be able to decide to go to a
low-power state based on the cgroup information
In addition to checking this in the idle thread, optionally check
this at other times so that you can trigger low-power states even if not
completely idle (possibly during the scheduler rebalancing check??)
3. modify the move to low-power modes to include disabling more components
in the system (including clocks), in the extreme case this would be a full
suspend.
This may include doing work to standardize power management for
devices more than it is to more readily be able to power down components.
this may include making an idle mode of 'stop all clocks except for
one alarm, until the alarm goes off, then advance the clocks to reflect
the time passed'
This probably does require the conceptual change from the fairly
monolithic 'you are in this C state' approach to a more fine grained 'the
CPU is in this C state, the video card is in that power management state,
the audio is in this other state.....'
David Lang
On Fri, Aug 6, 2010 at 4:59 PM, <[email protected]> wrote:
>
> now, android is betting that the apps are all developed specifically for the
> android from scratch, so having a different API is acceptable, even if it
> cuts them off from the rest of the *nix applications. For a phone this is
> not neccessarily an unreasonable stance, but as Android moves into the
> spaces where normal applications are in use (netbooks and tablets), this
> becomes a much shakier stance to take.
"Normal" apps work reasonably well -- they get halted when the screen
turns off, just like they do when my laptop suspends.
Wakelocks are useful for mobile-centric apps that you want to keep
running in the background, wake up and do work when the device is
"asleep", etc.
Brian
On Fri, 6 Aug 2010 [email protected] wrote:
> From this discussion, it looks to me like Android wants two key features
> that they don't see a way to get today
I have largely kept out of this discussion, but this was so outrageous
I had to say something.
> 1. the ability to decide to suspend while there are still some
> 'unimportant' apps running.
While this may be true in some literal sense, it certainly is not the
best way to view the situation. Linux already has the ability to
suspend (or to decide to suspend) whenever you want. What Android has
added is the ability to suspend conditionally, based on whether or not
some applications or drivers want to keep the system running.
Furthermore, this statement leaves out the primary purpose of
wakelocks: to avoid races between suspending and wakeup events. And it
also ignores a very important distinction: the difference between
drivers and applications. Wakelocks are used by both, but it has been
shown that only the wakelocks used by drivers need to be implemented in
the kernel -- the others can be implemented entirely in userspace.
All of these issues are addressed by Raphael's new wakeup_events code.
> 2. changes to idle/suspend so that they can get into a state of lower
> power consumption thatn any existing idle state (by being able to disable
> clocks), but still have some parts of the system powered (so that they are
> more awake than suspend)
This is nonsense. Nothing was changed. Instead, Android implemented
system suspend on their platform in a way that would leave some devices
running while the rest of the system powered down. There's nothing out
of the ordinary about this. Platforms are free to implement system
suspend in whatever way they deem most appropriate. On modern PCs, the
most appropriate technique is to go into ACPI's S3 or S4 state. On
embedded systems, the technique will vary from one platform to another.
> If these two features were available, I think that the rest of what they
> are looking for could be built up without requireing other changes.
They already _are_ available. Admittedly, only since quite recently.
(Rafael's new code was accepted during the 2.6.36 merge window.)
> In addition to these key features, the fact that they use suspend much
> more frequently means that the race condition between deciding to freeze
> and wake events happening is far more likely to cause them problems, so
> improvements in this area are needed. I don't think that there is any
> fundamental opposition to these improvements, just questions on how best
> to do it without causing performance problems.
By now, I think most of these questions have been answered.
On a slightly different tack, I have noticed that email discussions
concerning Android's wakelocks tend to evolve (I almost wrote
"devolve") along one of two paths: Either they start talking about ways
to integrate Android's goals into the mainline kernel, or else they
start complaining about the fact that Android uses system suspend so
aggressively and try to find ways to use deep-idle to achieve
equivalent results. Although the second path generally ends up being
much less productive than the first, it is the one that most
discussions seem to end up taking. Large portions of _this_ thread
have tended in that direction.
Alan Stern
On Fri, 6 Aug 2010, Alan Stern wrote:
> On Fri, 6 Aug 2010 [email protected] wrote:
>
>> From this discussion, it looks to me like Android wants two key features
>> that they don't see a way to get today
>
> I have largely kept out of this discussion, but this was so outrageous
> I had to say something.
sorry for misunderstanding things, thank you for speaking up to correct
the misunderstanding.
>> 1. the ability to decide to suspend while there are still some
>> 'unimportant' apps running.
>
> While this may be true in some literal sense, it certainly is not the
> best way to view the situation. Linux already has the ability to
> suspend (or to decide to suspend) whenever you want. What Android has
> added is the ability to suspend conditionally, based on whether or not
> some applications or drivers want to keep the system running.
Ok, aside from possibly drivers, what' stopping this from being done on a
valilla system today?
> Furthermore, this statement leaves out the primary purpose of
> wakelocks: to avoid races between suspending and wakeup events. And it
> also ignores a very important distinction: the difference between
> drivers and applications. Wakelocks are used by both, but it has been
> shown that only the wakelocks used by drivers need to be implemented in
> the kernel -- the others can be implemented entirely in userspace.
Ok, this is the first I've heard in this discussion that wakelocks would
not be available to userspace. In fact it was explicitly stated that
userspace applications called IOCTLs to get/release the wakelock.
many of my objections (voiced in another thread) about Android specific
features are not relavent if the wakelock in userspace is just part of
that application framework and not tied into the kernel.
> All of these issues are addressed by Raphael's new wakeup_events code.
Ok, then why is there still discussion about wakelocks at all if Raphael
has implemnetd the needed kernel functionality and userspace is Android
SDK specific? the heated replys from some people about what Android needs
(from people who I assumed were Android maintainers due to the way they
were answering questions) sure didn't sound like this was a solved
problem.
>> 2. changes to idle/suspend so that they can get into a state of lower
>> power consumption thatn any existing idle state (by being able to disable
>> clocks), but still have some parts of the system powered (so that they are
>> more awake than suspend)
>
> This is nonsense. Nothing was changed. Instead, Android implemented
> system suspend on their platform in a way that would leave some devices
> running while the rest of the system powered down. There's nothing out
> of the ordinary about this. Platforms are free to implement system
> suspend in whatever way they deem most appropriate. On modern PCs, the
> most appropriate technique is to go into ACPI's S3 or S4 state. On
> embedded systems, the technique will vary from one platform to another.
the difference is that not all suspends on Android are the same,
sometimes when you suspend you power down the audio components, sometimes
you don't.
As far as I am aware (and please correct meif I am mistaken), this is
significantly different from suspend elsewhere where suspend always takes
you to the same state.
>> If these two features were available, I think that the rest of what they
>> are looking for could be built up without requireing other changes.
>
> They already _are_ available. Admittedly, only since quite recently.
> (Rafael's new code was accepted during the 2.6.36 merge window.)
Do Brian and Arve agree that this solves their problem?
>> In addition to these key features, the fact that they use suspend much
>> more frequently means that the race condition between deciding to freeze
>> and wake events happening is far more likely to cause them problems, so
>> improvements in this area are needed. I don't think that there is any
>> fundamental opposition to these improvements, just questions on how best
>> to do it without causing performance problems.
>
> By now, I think most of these questions have been answered.
>
> On a slightly different tack, I have noticed that email discussions
> concerning Android's wakelocks tend to evolve (I almost wrote
> "devolve") along one of two paths: Either they start talking about ways
> to integrate Android's goals into the mainline kernel, or else they
> start complaining about the fact that Android uses system suspend so
> aggressively and try to find ways to use deep-idle to achieve
> equivalent results. Although the second path generally ends up being
> much less productive than the first, it is the one that most
> discussions seem to end up taking. Large portions of _this_ thread
> have tended in that direction.
to be fair, there have been numerous complaints about suspend being
separate from deep sleep long before Android. Linus' blow-up that resulted
in Hibernation and Suspend being separated from each other is a case in
point. He was making the point that there shouldn't be a difference
between the deepest sleep and suspend.
As deep sleep gains the ability to use even less power and as suspend
gains the ability to leave things on sometimes, the difference between
them is dissapearing. I wouldn't be at all surprised to see them start
overlaping soon. So it's not that I think Android should use deep sleeps
instead of suspend, but rather that suspend should just be the deepest
sleep, one mechanism instead of two.
David Lang
On Fri, 6 Aug 2010, Brian Swetland wrote:
> On Fri, Aug 6, 2010 at 4:59 PM, <[email protected]> wrote:
>>
>> now, android is betting that the apps are all developed specifically for the
>> android from scratch, so having a different API is acceptable, even if it
>> cuts them off from the rest of the *nix applications. For a phone this is
>> not neccessarily an unreasonable stance, but as Android moves into the
>> spaces where normal applications are in use (netbooks and tablets), this
>> becomes a much shakier stance to take.
>
> "Normal" apps work reasonably well -- they get halted when the screen
> turns off, just like they do when my laptop suspends.
>
> Wakelocks are useful for mobile-centric apps that you want to keep
> running in the background, wake up and do work when the device is
> "asleep", etc.
that description sounds far more like normal sleep power management that
suspending. especially since they want to set timers to wake the system up
and the defining characteristic of suspend (according to this thread) is
that timers don't fire while suspended.
as I am seeing it, there are two reasons why this don't "just work"
1. sleeping can't currently save as much power as suspending
2. the current logic for deciding to sleep can't ignore the other apps on
the system.
David Lang
2010/8/6 Alan Stern <[email protected]>:
> On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
>
>> count, tells you how many times the wakelock was activated. If a
>> wakelock prevented suspend for a long time a large count tells you it
>> handled a lot of events while a small count tells you it took a long
>> time to process the events, or the wakelock was not released properly.
>
> As noted, we already have this.
>
Almost. We have it when a device is passed in.
>> expire_count, tells you how many times the timeout expired. For the
>> input event wakelock in the android kernel (which has a timeout) an
>> expire count that matches the count tells you that someone opened an
>> input device but is not reading from it (this has happened several
>> times).
>
> This is a little tricky. ?Rafael's model currently does not allow
> wakeup events started by pm_wakeup_event() to be cancelled any way
> other than by having their timer expire. ?This essentially means that
> for some devices, expire_count will always be the same as count and for
> others it will always be 0. ?To change this would require adding an
> extra timer struct, which could be done (in fact, an earlier version of
> the code included it). ?It would be nice if we could avoid the need.
>
> Does Android use any kernel-internal wakelocks both with a timer and
> with active cancellation?
>
I don't know if they are all kernel-internal but these drivers appear
to use timeouts and active cancellation on the same wakelock:
wifi driver, mmc core, alarm driver, evdev (suspend blocker version
removes the timeout).
>> wake_count, tells you that this is the first wakelock that was
>> acquired in the resume path. This is currently less useful than I
>> would like on the Nexus One since it is usually "SMD_RPCCALL" which
>> does not tell me a lot.
>
> This could be done easily enough, but if it's not very useful then
> there's no point.
>
It is useful there is no other way to tell what triggered a wakeup,
but it would probably be better to just track wakeup interrupts/events
elsewhere.
>> active_since, tells you how long a a still active wakelock has been
>> active. If someone activated a wakelock and never released it, it will
>> be obvious here.
>
> Easily added. ?But you didn't mention any field saying whether the
> wakelock is currently active. ?That could be added too (although it
> would be racy -- but for detecting unreleased wakelocks you wouldn't
> care).
>
These are the reported stats, not the fields in the stats structure.
The wakelock code has an active flag. If we want to keep the
pm_stay_wake nesting (which I would argue against), we would need an
active count. It would also require a handle, which is a change Rafael
said would not fly.
>> total_time, total time the wake lock has been active. This one should
>> be obvious.
>
> Also easily added.
>
Only with a handle passed to all the calls.
>> sleep_time, total time the wake lock has been active when the screen was off.
>
> Not applicable to general systems. ?Is there anything like it that
> _would_ apply in general?
>
The screen off is how it is used on android, the stats is keyed of
what user space wrote to /sys/power/state. If "on" was written the
sleep time is not updated.
>> max_time, longest time the wakelock was active uninterrupted. This
>> used less often, but the battery on a device was draining fast, but
>> the problem went away before looking at the stats this will show if a
>> wakelock was active for a long time.
>
> Again, easily added. ?The only drawback is that all these additions
> will bloat the size of struct device. ?Of course, that's why you used
> separately-allocated structures for your wakelocks. ?Maybe we can
> change to do the same; it seems likely that the majority of device
> structures won't ever be used for wakeup events.
>
Since many wakelocks are not associated with s struct device we need a
separate object for this anyway.
>> >> and I would prefer that the kernel interfaces would
>> >> encourage drivers to block suspend until user space has consumed the
>> >> event, which works for the android user space, instead of just long
>> >> enough to work with a hypothetical user space power manager.
>
> Rafael doesn't _discourage_ drivers from doing this. ?However you have
> to keep in mind that many kernel developers are accustomed to working
> on systems (mostly PCs) with a different range of hardware devices from
> embedded systems like your phones. ?With PCI devices(*), for example,
> there's no clear point where a wakeup event gets handed off to
> userspace.
>
> On the other hand, there's no reason the input layer shouldn't use
> pm_stay_awake and pm_relax. ?It simply hasn't been implemented yet.
...
The merged user space interface makes this unclear to me. When I first
used suspend on android I had a power manager process that opened all
the input devices and reset a screen off timeout every time there was
an input event. If the input layer uses pm_stay_awake to block suspend
when the queue is not empty, this will deadlock with the current
interface since reading the wake count will block forever if an input
event occurred right after the power manager decides to suspend.
--
Arve Hj?nnev?g
On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
>
> that description sounds far more like normal sleep power management
> that suspending. especially since they want to set timers to wake
> the system up and the defining characteristic of suspend (according
> to this thread) is that timers don't fire while suspended.
>
> as I am seeing it, there are two reasons why this don't "just work"
>
> 1. sleeping can't currently save as much power as suspending
No, I don't think that's the case at all. The key thing here is that
*most* applications don't need to be modified to use suspend locks,
because even though they might be in an event loop, when the user user
turns off the display, the user generally doesn't want it doing things
on their behalf.
Again, take for example the Mac Book, since Apple has gotten this
right for most users' use cases. When you close the lid, you even if
the application is under the misguided belief that it should be
checking every five seconds to see whether or not the web page has
reloaded --- actually, that's not what you want. You probably want
the application to be forcibly put to sleep. So the whole point of
the suspend blocker design is that you don't have to modify most
applications; they just simply get put to sleep when you close the
MacBook lid, or, in the case of the Android device, you push the
button that turns off the screen.
So the reason why this doesn't work is that power management for small
mobile devices *is* different from power management for laptops and
data center servers, and if you want a rich application ecosystem,
it's best if you don't require them to be specially tuned to use the
absolute minimum power. (And that means waking up every 30 seconds
might be too much; as Brian and Arve have pointed out, with the G1 in
airplane mode, the CPU might be waking up once every half hour or more
--- and at that rate, powertop will be waking up the CPU more than
Android system would be doing so.)
So the real key here is to take most applications, which may be
written using techniques that might be considered well written from a
laptop point of view, but not for a cell phone, and not require
modifications. Even though the application writer might think it's
doing well by waking up every 15 seconds, if the laptop lid is down,
or if the screen is off, for **most** applications, it should be
forcibly put to sleep.
It's only the rare applications that should really be allowed to run
while screen is off. And it's only those applications that need
modifications to use suspend blocker. From your earlier comments, it
seems that this is the key point which you are missing. (No doubt,
some of these applications that do need to know about suspend blockers
are important ones; ones that make sure the battery isn't about to
blow up, or ones which silently wake up every 10-15 minutes to pull
down fresh mail for you from your mail server. But those applications
are the exception, not the rule.)
Best regards,
- Ted
On Fri, Aug 06, 2010 at 06:00:34PM -0700, [email protected] wrote:
>
> today there are two ways of this happening, via the idle approach
> (on everything except Android), or via suspend (on Android)
>
Most other devices use a lot more power at idle; in some cases it's
because the hardware just isn't as power optimized (why bother, when
you have 94,000 mWh of power at your disposal with a 6 cell laptop
battery, as opposed to the 800-1000 mWh that you might have on a cell
phone battery). In other cases, it's because the kernel and the
low-level software stack (never mind the applications) are waking up
the CPU too darned often --- in other words, idle simply isn't idle
enough.
So you may want to consider whether part of the problem is that
general purpose Linux systems need a radical redesign to get power
utilization down to those sorts of levels --- where the CPU might only
be waking up once every half-hour or so, and then only do actual
useful work.
Can you get there by assuming that every single application is
competently written? In an idle approach, you have to. That way lies
Maemo, where installing just one bad application will cut your battery
life time by a factor of 2-3. You could try stopping processes by
using kill -STOP, but this at that point, you've moved into Android
strategy of "suspend". And the only question is what is the most
efficient way to allow the system to run when there is true work that
needs to be done, and how to avoid deadlocks by stopping processes
that might be holding user space locks --- and to administer when and
how to suspend the processes.
Sure, you could do someting amazing complicated using cgroups, and
user space processes that have to wake up the CPU every 30 seconds to
see if it's safe to suspend the system --- but why not just use the
system which is being used by 200,000 new phones every day? It's
simple and it works. And unlike Maemo, untrustworthy applications
don't end up chewing up your battery lifetime.
- Ted
On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> 2010/8/6 Alan Stern <[email protected]>:
> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> >
> >> count, tells you how many times the wakelock was activated. If a
> >> wakelock prevented suspend for a long time a large count tells you it
> >> handled a lot of events while a small count tells you it took a long
> >> time to process the events, or the wakelock was not released properly.
> >
> > As noted, we already have this.
> >
>
> Almost. We have it when a device is passed in.
Sure. And what are the other cases (details, please)?
> >> expire_count, tells you how many times the timeout expired. For the
> >> input event wakelock in the android kernel (which has a timeout) an
> >> expire count that matches the count tells you that someone opened an
> >> input device but is not reading from it (this has happened several
> >> times).
> >
> > This is a little tricky. Rafael's model currently does not allow
> > wakeup events started by pm_wakeup_event() to be cancelled any way
> > other than by having their timer expire. This essentially means that
> > for some devices, expire_count will always be the same as count and for
> > others it will always be 0. To change this would require adding an
> > extra timer struct, which could be done (in fact, an earlier version of
> > the code included it). It would be nice if we could avoid the need.
> >
> > Does Android use any kernel-internal wakelocks both with a timer and
> > with active cancellation?
> >
>
> I don't know if they are all kernel-internal but these drivers appear
> to use timeouts and active cancellation on the same wakelock:
> wifi driver, mmc core, alarm driver, evdev (suspend blocker version
> removes the timeout).
You previously said you didn't need timeouted wakelocks in the kernel, so
I guess that was incorrect.
> >> wake_count, tells you that this is the first wakelock that was
> >> acquired in the resume path. This is currently less useful than I
> >> would like on the Nexus One since it is usually "SMD_RPCCALL" which
> >> does not tell me a lot.
> >
> > This could be done easily enough, but if it's not very useful then
> > there's no point.
> >
> It is useful there is no other way to tell what triggered a wakeup,
> but it would probably be better to just track wakeup interrupts/events
> elsewhere.
>
> >> active_since, tells you how long a a still active wakelock has been
> >> active. If someone activated a wakelock and never released it, it will
> >> be obvious here.
> >
> > Easily added. But you didn't mention any field saying whether the
> > wakelock is currently active. That could be added too (although it
> > would be racy -- but for detecting unreleased wakelocks you wouldn't
> > care).
> >
>
> These are the reported stats, not the fields in the stats structure.
> The wakelock code has an active flag. If we want to keep the
> pm_stay_wake nesting (which I would argue against), we would need an
> active count. It would also require a handle, which is a change Rafael
> said would not fly.
>
> >> total_time, total time the wake lock has been active. This one should
> >> be obvious.
> >
> > Also easily added.
> >
> Only with a handle passed to all the calls.
Well, I'm kind of tired of this "my solution is the only acceptable one"
mindset. IMHO, it's totally counter productive.
> >> sleep_time, total time the wake lock has been active when the screen was off.
> >
> > Not applicable to general systems. Is there anything like it that
> > _would_ apply in general?
> >
>
> The screen off is how it is used on android, the stats is keyed of
> what user space wrote to /sys/power/state. If "on" was written the
> sleep time is not updated.
>
> >> max_time, longest time the wakelock was active uninterrupted. This
> >> used less often, but the battery on a device was draining fast, but
> >> the problem went away before looking at the stats this will show if a
> >> wakelock was active for a long time.
> >
> > Again, easily added. The only drawback is that all these additions
> > will bloat the size of struct device. Of course, that's why you used
> > separately-allocated structures for your wakelocks. Maybe we can
> > change to do the same; it seems likely that the majority of device
> > structures won't ever be used for wakeup events.
> >
>
> Since many wakelocks are not associated with s struct device we need a
> separate object for this anyway.
>
> >> >> and I would prefer that the kernel interfaces would
> >> >> encourage drivers to block suspend until user space has consumed the
> >> >> event, which works for the android user space, instead of just long
> >> >> enough to work with a hypothetical user space power manager.
> >
> > Rafael doesn't _discourage_ drivers from doing this. However you have
> > to keep in mind that many kernel developers are accustomed to working
> > on systems (mostly PCs) with a different range of hardware devices from
> > embedded systems like your phones. With PCI devices(*), for example,
> > there's no clear point where a wakeup event gets handed off to
> > userspace.
> >
> > On the other hand, there's no reason the input layer shouldn't use
> > pm_stay_awake and pm_relax. It simply hasn't been implemented yet.
> ...
>
> The merged user space interface makes this unclear to me. When I first
> used suspend on android I had a power manager process that opened all
> the input devices and reset a screen off timeout every time there was
> an input event. If the input layer uses pm_stay_awake to block suspend
> when the queue is not empty, this will deadlock with the current
> interface since reading the wake count will block forever if an input
> event occurred right after the power manager decides to suspend.
No, in that case suspend will be aborted, IIUC.
Thanks,
Rafael
On Saturday, August 07, 2010, Rafael J. Wysocki wrote:
> On Friday, August 06, 2010, Alan Stern wrote:
> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> ...
> > But what sorts of things qualify as wakeup events? Right now, the code
> > handles only events coming by way of the PME# signal (or its platform
> > equivalent). But that signal usually gets activated only when a PCI
> > device is in a low-power mode; if the device is at full power then it
> > simply generates an IRQ. It's the same event, but reported to the
> > kernel in a different way. So consider...
> >
> > Case 1: The system is suspending and the PCI device has already been
> > placed in D3hot when an event occurs. PME# is activated,
> > the wakeup event is reported, the suspend is aborted, and the
> > system won't try to suspend again for at least 100 ms. Good.
> >
> > Case 2: The system is running normally and the PCI device is at full
> > power when an event occurs. PME# isn't activated and
> > pm_wakeup_event doesn't get called. Then when the system
> > tries to suspend 25 ms later, there's nothing to prevent it
> > even though the event is still being processed. Bad.
> >
> > In case 2 the race has not been resolved. It seems to me that the
> > only proper solution is to call pm_wakeup_event for _every_ PCI
> > interrupt. This may be too much to add to a hot path, but what's the
> > alternative?
>
> Arguably not every PCI interrupt should be regarded as a wakeup event, so
> I think we can simply say in the cases when that's necessary the driver should
> be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> appropriate.
>
> My patch only added it to the bus-level code which covered the PME-based
> wakeup events that _cannot_ be handled by device drivers.
Also please note that it depends a good deal on the definition of a "wakeup
event". Under the definition used when my patch was being developed, ie. that
wakeup events are the events that would wake up the system from a sleep state,
PCI interrupts cannot be wakeup events, unless the given device remains in the
full power state although the system has been suspended (standard PCI devices
are not allowed to generate signals except for PME from low-power states).
Thanks,
Rafael
On Saturday, August 07, 2010, [email protected] wrote:
> On Sat, 7 Aug 2010, Mark Brown wrote:
>
> > On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
> >> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
...
> What we want to have happen in an ideal world is
>
> when the storage isn't needed (between reads) the storage should shutdown
> to as low a power state as possible.
>
> when the CPU isn't needed (between decoding bursts) the CPU and as much of
> the system as possible (potentially including some banks of RAM) should
> shutdown to as low a power state as possible.
Unfortunately, the criteria for "not being needed" are not really
straightforward and one of the wakelocks' roles is to work around this issue.
> today there are two ways of this happening, via the idle approach (on
> everything except Android), or via suspend (on Android)
>
> Given that many platforms cannot go to into suspend while still playing
> audio, the idle approach is not going to be able to be eliminated (and in
> fact will be the most common approach to be used/deugged in terms of the
> types of platforms), it seems to me that there may be a significant amount
> of value in seeing if there is a way to change Android to use this
> approach as well instead of having two different systems competing to do
> the same job.
There is a fundamental obstacle to that, though. Namely, the Android
developers say that the idle-based approach doesn't lead to sufficient energy
savings due to periodic timers and "polling applications". Technically that
boils down to the interrupt sources that remain active in the idle-based case
and that are shut down during suspend. If you found a way to deactivate all of
them from the idle context in a non-racy fashion, that would probably satisfy
the Android's needs too.
Thanks,
Rafael
On Saturday, August 07, 2010, Ted Ts'o wrote:
> On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
> >
> > that description sounds far more like normal sleep power management
> > that suspending. especially since they want to set timers to wake
> > the system up and the defining characteristic of suspend (according
> > to this thread) is that timers don't fire while suspended.
> >
> > as I am seeing it, there are two reasons why this don't "just work"
> >
> > 1. sleeping can't currently save as much power as suspending
>
> No, I don't think that's the case at all. The key thing here is that
> *most* applications don't need to be modified to use suspend locks,
> because even though they might be in an event loop, when the user user
> turns off the display, the user generally doesn't want it doing things
> on their behalf.
>
> Again, take for example the Mac Book, since Apple has gotten this
> right for most users' use cases. When you close the lid, you even if
> the application is under the misguided belief that it should be
> checking every five seconds to see whether or not the web page has
> reloaded --- actually, that's not what you want. You probably want
> the application to be forcibly put to sleep. So the whole point of
> the suspend blocker design is that you don't have to modify most
> applications; they just simply get put to sleep when you close the
> MacBook lid, or, in the case of the Android device, you push the
> button that turns off the screen.
But in principle that need not mean suspending the entire system.
To get applications out of the way, you need to freeze user space.
However, that's not sufficient, because in addition to that you need to
prevent deactivate the majority of interrupt sources to avoid waking up the
CPU (from C-states) too often.
Thanks,
Rafael
On Saturday, August 07, 2010, Rafael J. Wysocki wrote:
> On Saturday, August 07, 2010, Ted Ts'o wrote:
> > On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
> > >
> > > that description sounds far more like normal sleep power management
> > > that suspending. especially since they want to set timers to wake
> > > the system up and the defining characteristic of suspend (according
> > > to this thread) is that timers don't fire while suspended.
> > >
> > > as I am seeing it, there are two reasons why this don't "just work"
> > >
> > > 1. sleeping can't currently save as much power as suspending
> >
> > No, I don't think that's the case at all. The key thing here is that
> > *most* applications don't need to be modified to use suspend locks,
> > because even though they might be in an event loop, when the user user
> > turns off the display, the user generally doesn't want it doing things
> > on their behalf.
> >
> > Again, take for example the Mac Book, since Apple has gotten this
> > right for most users' use cases. When you close the lid, you even if
> > the application is under the misguided belief that it should be
> > checking every five seconds to see whether or not the web page has
> > reloaded --- actually, that's not what you want. You probably want
> > the application to be forcibly put to sleep. So the whole point of
> > the suspend blocker design is that you don't have to modify most
> > applications; they just simply get put to sleep when you close the
> > MacBook lid, or, in the case of the Android device, you push the
> > button that turns off the screen.
>
> But in principle that need not mean suspending the entire system.
> To get applications out of the way, you need to freeze user space.
> However, that's not sufficient, because in addition to that you need to
> prevent deactivate the majority of interrupt sources to avoid waking up the
> CPU (from C-states) too often.
s/prevent deactivate/deactivate/
Rafael
On Sat, 7 Aug 2010, Ted Ts'o wrote:
> On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
>>
>> that description sounds far more like normal sleep power management
>> that suspending. especially since they want to set timers to wake
>> the system up and the defining characteristic of suspend (according
>> to this thread) is that timers don't fire while suspended.
>>
>> as I am seeing it, there are two reasons why this don't "just work"
>>
>> 1. sleeping can't currently save as much power as suspending
>
> No, I don't think that's the case at all. The key thing here is that
> *most* applications don't need to be modified to use suspend locks,
> because even though they might be in an event loop, when the user user
> turns off the display, the user generally doesn't want it doing things
> on their behalf.
>
> Again, take for example the Mac Book, since Apple has gotten this
> right for most users' use cases. When you close the lid, you even if
> the application is under the misguided belief that it should be
> checking every five seconds to see whether or not the web page has
> reloaded --- actually, that's not what you want. You probably want
> the application to be forcibly put to sleep. So the whole point of
> the suspend blocker design is that you don't have to modify most
> applications; they just simply get put to sleep when you close the
> MacBook lid, or, in the case of the Android device, you push the
> button that turns off the screen.
this doesn't require wakelocks or anything else new. all it takes is
setting the policy that you don't want anything to run when the lid is
closed and a switch to detect the lid being closed. Laptops have been
doing this for years.
> So the reason why this doesn't work is that power management for small
> mobile devices *is* different from power management for laptops and
> data center servers, and if you want a rich application ecosystem,
> it's best if you don't require them to be specially tuned to use the
> absolute minimum power. (And that means waking up every 30 seconds
> might be too much; as Brian and Arve have pointed out, with the G1 in
> airplane mode, the CPU might be waking up once every half hour or more
> --- and at that rate, powertop will be waking up the CPU more than
> Android system would be doing so.)
note that nothing that I have proposed would wake up a sleeping system.
the 'every several seconds' thing that I proposed was that on a system
that's fully awake, busy and doesn't want to sleep, there would be a
context switch periodically by a privilaged process so that the system
would not end up deciding it was idle and halt everything. Now that I
think about this more, it's not needed if you want to override this to
keep everything running for a significant amount of time, just change the
power saving mode from "sleep if a privilaged task isn't running" to
"disable suspend". This can be done today by changing the right sysfs
value. normal privilaged processes would never need to do this, only
gatekeeper daemons that want to let unprivilaged processes run even if no
privilaged processes want to run would need to do this (i.e. in the
current system, whatever process controls the screen would probably be
right)
> So the real key here is to take most applications, which may be
> written using techniques that might be considered well written from a
> laptop point of view, but not for a cell phone, and not require
> modifications. Even though the application writer might think it's
> doing well by waking up every 15 seconds, if the laptop lid is down,
> or if the screen is off, for **most** applications, it should be
> forcibly put to sleep.
>
> It's only the rare applications that should really be allowed to run
> while screen is off. And it's only those applications that need
> modifications to use suspend blocker. From your earlier comments, it
> seems that this is the key point which you are missing. (No doubt,
> some of these applications that do need to know about suspend blockers
> are important ones; ones that make sure the battery isn't about to
> blow up, or ones which silently wake up every 10-15 minutes to pull
> down fresh mail for you from your mail server. But those applications
> are the exception, not the rule.)
the question is what it takes to make an application privilaged like this.
what I proposed was to make it possible for the user/admin to select what
applications are allowed to keep the system awake.
wakelocks require that the application developer decide that they want to
keep the system awake as well as the user/admin
take your example of a mail client waking up every 15 min.
with Android it needs to be privilaged to grab the wakelock while fetching
the mail, it also needs to use a privilaged API to set the wakeups to wake
it up at those times.
with what I proposed all you need to do is to tag the application as power
privilaged and then if the application sleeps for 15 min between doing
thing the system will wake up every 15 min, work for a short time, then go
back to sleep.
if you want to put everything to sleep when the screen blanks, that's
trivial to do.
the fun starts when you want to say that there are some things you don't
want to put to sleep.
do you let some processes run while halting others?
in which case how do you prevent deadlocks?
on the other hand, sleeping again is simple, you sleep when there
is nothing more to run
or do you let wasteful processes run while you are awake?
this avoids deadlocks, but how do you decide when to sleep again?
Android approaches this by requiring that any program that a user may want
to keep running must be modified to use wakelocks.
My suggestion was that the system ignore other processes when deciding if
the system is idle enough to put to sleep.
Yes the Android approach works reasonably well on the phones where
everything must currently be custom developed anyway (due to screen and UI
constraints), but as Android starts getting used on laptops and other
larger devices is that really still the right approach? or would it be
better to have something that could use standard software in the
privilaged mode?
to use your example of a mail client, why should someone not be able to
use fetchmail to get their mail instead of requiring that fetchmail be
modified to use wavelocks (or a substatute written)?
the theoretical best approach would probably look nothing like either of
these. Instead it would probably either
forbid privilaged processes from having blocking dependancies on
unprivilaged processes (you can then just halt the unprivilaged processes
when you blank the screen and let idle sleep deal with the privilged
processes)
or
use something like priority inheritance through userspace so that if a
privilaged process blocks on something where it's waiting for an
unprivilaged process, that unprivilaged process gets woken up and allowed
to run until it unblocks the privilaged process.
both of these have been deemed too hard
David Lang
On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
> On Saturday, August 07, 2010, [email protected] wrote:
>> On Sat, 7 Aug 2010, Mark Brown wrote:
>>
>>> On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
>>>> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> ...
>> What we want to have happen in an ideal world is
>>
>> when the storage isn't needed (between reads) the storage should shutdown
>> to as low a power state as possible.
>>
>> when the CPU isn't needed (between decoding bursts) the CPU and as much of
>> the system as possible (potentially including some banks of RAM) should
>> shutdown to as low a power state as possible.
>
> Unfortunately, the criteria for "not being needed" are not really
> straightforward and one of the wakelocks' roles is to work around this issue.
if you can ignore the activity caused by the other "unimportant" processes
in the system, why is this much different then just the one process
running, in which case standard power management sleeps work pretty well.
>> today there are two ways of this happening, via the idle approach (on
>> everything except Android), or via suspend (on Android)
>>
>> Given that many platforms cannot go to into suspend while still playing
>> audio, the idle approach is not going to be able to be eliminated (and in
>> fact will be the most common approach to be used/deugged in terms of the
>> types of platforms), it seems to me that there may be a significant amount
>> of value in seeing if there is a way to change Android to use this
>> approach as well instead of having two different systems competing to do
>> the same job.
>
> There is a fundamental obstacle to that, though. Namely, the Android
> developers say that the idle-based approach doesn't lead to sufficient energy
> savings due to periodic timers and "polling applications".
polling applications can be solved by deciding that they aren't going to
be allowed to affect the power management decision (don't consider their
CPU useage when deciding to go to sleep, don't consider their timers when
deciding when to wake back up)
> Technically that
> boils down to the interrupt sources that remain active in the idle-based case
> and that are shut down during suspend. If you found a way to deactivate all of
> them from the idle context in a non-racy fashion, that would probably satisfy
> the Android's needs too.
well, we already have similar capibility for other peripherals (I keep
pointing to drive spin down as an example), the key to avoiding the
races seems to be in the drivers supporting this.
the fact that Android is making it possible for suspend to selectivly
avoid disabling them makes me think that a lot of the work needed to make
this happen has probably been done. look at what would happen in a suspend
if it decided to leave everything else on and just disable the one thing,
that should e the same thing that happens if you are just disabling that
one thing for idle sleep.
David Lang
2010/8/7 Rafael J. Wysocki <[email protected]>:
> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>> 2010/8/6 Alan Stern <[email protected]>:
>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
>> >
>> >> count, tells you how many times the wakelock was activated. If a
>> >> wakelock prevented suspend for a long time a large count tells you it
>> >> handled a lot of events while a small count tells you it took a long
>> >> time to process the events, or the wakelock was not released properly.
>> >
>> > As noted, we already have this.
>> >
>>
>> Almost. We have it when a device is passed in.
>
> Sure. ?And what are the other cases (details, please)?
>
The suspend blockers I added I my suspend blocker patchset were not
directly associated with a device. The evdev changes could be modified
to share a device, but it would give less detail since a separate
queue is created for each client that opens the device. The suspend
blocking work api would have to change so the caller to passes a
device in, which I think would make that api less flexible. Mostly the
problem is that we need separate stats for wakelocks created by a
single driver. For instance we will still need a user-space interface
to block suspend on android devices (lower level services than the
power manager need to block suspend), with the stats in the device
struct we have to create a new device for every wakelock user space
creates in the kernel.
There is also the issue of reading the stats. It is a lot easier to
read a single stats file, than looping though every device on the
system (when most of the devices never block suspend).
>> >> expire_count, tells you how many times the timeout expired. For the
>> >> input event wakelock in the android kernel (which has a timeout) an
>> >> expire count that matches the count tells you that someone opened an
>> >> input device but is not reading from it (this has happened several
>> >> times).
>> >
>> > This is a little tricky. ?Rafael's model currently does not allow
>> > wakeup events started by pm_wakeup_event() to be cancelled any way
>> > other than by having their timer expire. ?This essentially means that
>> > for some devices, expire_count will always be the same as count and for
>> > others it will always be 0. ?To change this would require adding an
>> > extra timer struct, which could be done (in fact, an earlier version of
>> > the code included it). ?It would be nice if we could avoid the need.
>> >
>> > Does Android use any kernel-internal wakelocks both with a timer and
>> > with active cancellation?
>> >
>>
>> I don't know if they are all kernel-internal but these drivers appear
>> to use timeouts and active cancellation on the same wakelock:
>> wifi driver, mmc core, alarm driver, evdev (suspend blocker version
>> removes the timeout).
>
> You previously said you didn't need timeouted wakelocks in the kernel, so
> I guess that was incorrect.
>
I don't know what you are reffering to. We have always stated that we
need timeouts in the kernel to pass events through other kernel layers
that do not use wakelocks (that list is much longer than the list
above which mixes timeouts and unlock on the same wakelock). The only
feature we do not use is the timeout feature in the user space
interface to kernel wakelocks.
>> >> wake_count, tells you that this is the first wakelock that was
>> >> acquired in the resume path. This is currently less useful than I
>> >> would like on the Nexus One since it is usually "SMD_RPCCALL" which
>> >> does not tell me a lot.
>> >
>> > This could be done easily enough, but if it's not very useful then
>> > there's no point.
>> >
>> It is useful there is no other way to tell what triggered a wakeup,
>> but it would probably be better to just track wakeup interrupts/events
>> elsewhere.
>>
>> >> active_since, tells you how long a a still active wakelock has been
>> >> active. If someone activated a wakelock and never released it, it will
>> >> be obvious here.
>> >
>> > Easily added. ?But you didn't mention any field saying whether the
>> > wakelock is currently active. ?That could be added too (although it
>> > would be racy -- but for detecting unreleased wakelocks you wouldn't
>> > care).
>> >
>>
>> These are the reported stats, not the fields in the stats structure.
>> The wakelock code has an active flag. If we want to keep the
>> pm_stay_wake nesting (which I would argue against), we would need an
>> active count. It would also require a handle, which is a change Rafael
>> said would not fly.
>>
>> >> total_time, total time the wake lock has been active. This one should
>> >> be obvious.
>> >
>> > Also easily added.
>> >
>> Only with a handle passed to all the calls.
>
> Well, I'm kind of tired of this "my solution is the only acceptable one"
> mindset. ?IMHO, it's totally counter productive.
>
How do you propose to track how long a driver has blocked suspend when
you have an unblock call that takes no arguments.
>> >> sleep_time, total time the wake lock has been active when the screen was off.
>> >
>> > Not applicable to general systems. ?Is there anything like it that
>> > _would_ apply in general?
>> >
>>
>> The screen off is how it is used on android, the stats is keyed of
>> what user space wrote to /sys/power/state. If "on" was written the
>> sleep time is not updated.
>>
>> >> max_time, longest time the wakelock was active uninterrupted. This
>> >> used less often, but the battery on a device was draining fast, but
>> >> the problem went away before looking at the stats this will show if a
>> >> wakelock was active for a long time.
>> >
>> > Again, easily added. ?The only drawback is that all these additions
>> > will bloat the size of struct device. ?Of course, that's why you used
>> > separately-allocated structures for your wakelocks. ?Maybe we can
>> > change to do the same; it seems likely that the majority of device
>> > structures won't ever be used for wakeup events.
>> >
>>
>> Since many wakelocks are not associated with s struct device we need a
>> separate object for this anyway.
>>
>> >> >> and I would prefer that the kernel interfaces would
>> >> >> encourage drivers to block suspend until user space has consumed the
>> >> >> event, which works for the android user space, instead of just long
>> >> >> enough to work with a hypothetical user space power manager.
>> >
>> > Rafael doesn't _discourage_ drivers from doing this. ?However you have
>> > to keep in mind that many kernel developers are accustomed to working
>> > on systems (mostly PCs) with a different range of hardware devices from
>> > embedded systems like your phones. ?With PCI devices(*), for example,
>> > there's no clear point where a wakeup event gets handed off to
>> > userspace.
>> >
>> > On the other hand, there's no reason the input layer shouldn't use
>> > pm_stay_awake and pm_relax. ?It simply hasn't been implemented yet.
>> ...
>>
>> The merged user space interface makes this unclear to me. When I first
>> used suspend on android I had a power manager process that opened all
>> the input devices and reset a screen off timeout every time there was
>> an input event. If the input layer uses pm_stay_awake to block suspend
>> when the queue is not empty, this will deadlock with the current
>> interface since reading the wake count will block forever if an input
>> event occurred right after the power manager decides to suspend.
>
> No, in that case suspend will be aborted, IIUC.
>
How? Your pm_get_wakeup_count function loops until events_in_progress becomes 0.
--
Arve Hj?nnev?g
2010/8/7 Arve Hj?nnev?g <[email protected]>:
> 2010/8/7 Rafael J. Wysocki <[email protected]>:
>> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>>> 2010/8/6 Alan Stern <[email protected]>:
>>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
...
>>> >> total_time, total time the wake lock has been active. This one should
>>> >> be obvious.
>>> >
>>> > Also easily added.
>>> >
>>> Only with a handle passed to all the calls.
>>
>> Well, I'm kind of tired of this "my solution is the only acceptable one"
>> mindset. ?IMHO, it's totally counter productive.
>>
>
> How do you propose to track how long a driver has blocked suspend when
> you have an unblock call that takes no arguments.
>
Also, I did not not see a response to my question about why you don't
want to pass a handle.
--
Arve Hj?nnev?g
On Fri, Aug 06, 2010 at 05:36:42PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:
> > services in themselves (like system monitoring). It's really just
> > semantics to treat them differently to something like a cellular modem -
> > at a high level they're both just independant processors ticking away
> > without the application processor.
> I agree that a smartphone's cellular modem can be argued to be very
> similar to wake-on-LAN. The smartphone applications that seem to me
> to be very different from wake-on-LAN are things like audio playback,
> where the system is providing service to the user during the time that
> it is suspended.
The cellular modem case includes not just hanging off the network but
also being on a call - the voice path for a phone call doesn't need the
CPU to do anything. It's probably best to view a phone as a bunch of
interconnected systems that happen to sit in the same box, and there's
various design decisions that can be taken about which systems own the
shared components.
On Fri, 6 Aug 2010 [email protected] wrote:
> >> 1. the ability to decide to suspend while there are still some
> >> 'unimportant' apps running.
> >
> > While this may be true in some literal sense, it certainly is not the
> > best way to view the situation. Linux already has the ability to
> > suspend (or to decide to suspend) whenever you want. What Android has
> > added is the ability to suspend conditionally, based on whether or not
> > some applications or drivers want to keep the system running.
>
> Ok, aside from possibly drivers, what' stopping this from being done on a
> valilla system today?
Nothing much. Mainly just the fact that Rafael's code is so new. It
hasn't yet been integrated into the drivers that should use it.
> > Furthermore, this statement leaves out the primary purpose of
> > wakelocks: to avoid races between suspending and wakeup events. And it
> > also ignores a very important distinction: the difference between
> > drivers and applications. Wakelocks are used by both, but it has been
> > shown that only the wakelocks used by drivers need to be implemented in
> > the kernel -- the others can be implemented entirely in userspace.
>
> Ok, this is the first I've heard in this discussion that wakelocks would
> not be available to userspace. In fact it was explicitly stated that
> userspace applications called IOCTLs to get/release the wakelock.
Android's wakelock implementation does make wakelocks available to
userspace. In Rafael's approach there is nothing comparable. Instead
"userspace wakelock"-equivalents have to be handled by a power manager
program.
> many of my objections (voiced in another thread) about Android specific
> features are not relavent if the wakelock in userspace is just part of
> that application framework and not tied into the kernel.
>
> > All of these issues are addressed by Raphael's new wakeup_events code.
>
> Ok, then why is there still discussion about wakelocks at all if Raphael
> has implemnetd the needed kernel functionality and userspace is Android
> SDK specific?
This thread started when Paul posted his list of requirements for
Android power management (or power management in general). It wasn't
really specific to wakelocks, but people brought them up when
discussing how those requirements are currently being met.
In fact, it seems to me that _you_ are the person most responsible for
prolonging this discussion.
> the heated replys from some people about what Android needs
> (from people who I assumed were Android maintainers due to the way they
> were answering questions) sure didn't sound like this was a solved
> problem.
The solution is still in its early stages, and it hasn't yet been
accepted into Android. Things will improve over time. (Or they won't,
and Android will continue to go its separate way...)
> > This is nonsense. Nothing was changed. Instead, Android implemented
> > system suspend on their platform in a way that would leave some devices
> > running while the rest of the system powered down. There's nothing out
> > of the ordinary about this. Platforms are free to implement system
> > suspend in whatever way they deem most appropriate. On modern PCs, the
> > most appropriate technique is to go into ACPI's S3 or S4 state. On
> > embedded systems, the technique will vary from one platform to another.
>
> the difference is that not all suspends on Android are the same,
> sometimes when you suspend you power down the audio components, sometimes
> you don't.
That's not a difference; it is their decision. For all you or I know,
other platforms have been doing the same thing for years.
> As far as I am aware (and please correct meif I am mistaken), this is
> significantly different from suspend elsewhere where suspend always takes
> you to the same state.
You are mistaken. Or at best, you are overgeneralizing. It may be
true now that all other suspend implementations always go to the same
state, but there is no requirement that they do so.
> >> If these two features were available, I think that the rest of what they
> >> are looking for could be built up without requireing other changes.
> >
> > They already _are_ available. Admittedly, only since quite recently.
> > (Rafael's new code was accepted during the 2.6.36 merge window.)
>
> Do Brian and Arve agree that this solves their problem?
I think you should ask them instead of asking me.
> to be fair, there have been numerous complaints about suspend being
> separate from deep sleep long before Android. Linus' blow-up that resulted
> in Hibernation and Suspend being separated from each other is a case in
> point. He was making the point that there shouldn't be a difference
> between the deepest sleep and suspend.
This may be controversial, but I think Rafael will agree when I say
that (in this one respect) Linus was wrong. Separating hibernation
from suspend makes sense, and I agree that the differences between
deepest idle and suspend should be minimized. But to get rid of them
altogether would be wrong (and probably not possible anyway).
> As deep sleep gains the ability to use even less power and as suspend
> gains the ability to leave things on sometimes, the difference between
> them is dissapearing. I wouldn't be at all surprised to see them start
> overlaping soon. So it's not that I think Android should use deep sleeps
> instead of suspend, but rather that suspend should just be the deepest
> sleep, one mechanism instead of two.
I disagree. There are critical differences between them:
Suspend uses the freezer and idle doesn't.
Suspend generally forces devices to go into their low-power
states immediately, whereas idle tends to leave unused devices
at full power for some time before going to low power (to
minimize average latency).
Overall, suspend generally has longer latency than idle. (This
varies among platforms.)
The set of wakeup sources (including timers) is different.
On some systems, suspend uses platform-specific mechanisms to
go into lower power states than are available to idle.
There may be others I have left out.
Alan Stern
On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
> > Arguably not every PCI interrupt should be regarded as a wakeup event, so
> > I think we can simply say in the cases when that's necessary the driver should
> > be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> > appropriate.
> >
> > My patch only added it to the bus-level code which covered the PME-based
> > wakeup events that _cannot_ be handled by device drivers.
In other words, your bus-level changes were a necessary but not
sufficient start. I can buy that.
> Also please note that it depends a good deal on the definition of a "wakeup
> event". Under the definition used when my patch was being developed, ie. that
> wakeup events are the events that would wake up the system from a sleep state,
> PCI interrupts cannot be wakeup events, unless the given device remains in the
> full power state although the system has been suspended (standard PCI devices
> are not allowed to generate signals except for PME from low-power states).
Um, what do you mean by "event"? Let's take a concrete example.
Suppose you have a system where you want USB plug or unplug events to
cause a wakeup. This is relevant to the discussion at hand if your USB
host controller is a PCI device.
By your reckoning, a plug or unplug event that occurs while the system
is asleep would be a wakeup event by definition. And yet you say that
the same plug or unplug event occurring while the controller was at
full power would not count as a wakeup event? And in particular, it
should not prevent the system from suspending before the event can be
fully processed? That doesn't make sense. The same event is the same
event, regardless of the context in which it occurs. If it is treated
as a wakeup event in context then it should be treated as a wakeup
event in other contexts too.
Alan Stern
On Sat, Aug 07, 2010 at 02:07:18PM +0100, Mark Brown wrote:
> On Fri, Aug 06, 2010 at 05:36:42PM -0700, Paul E. McKenney wrote:
> > On Sat, Aug 07, 2010 at 01:14:32AM +0100, Mark Brown wrote:
>
> > > services in themselves (like system monitoring). It's really just
> > > semantics to treat them differently to something like a cellular modem -
> > > at a high level they're both just independant processors ticking away
> > > without the application processor.
>
> > I agree that a smartphone's cellular modem can be argued to be very
> > similar to wake-on-LAN. The smartphone applications that seem to me
> > to be very different from wake-on-LAN are things like audio playback,
> > where the system is providing service to the user during the time that
> > it is suspended.
>
> The cellular modem case includes not just hanging off the network but
> also being on a call - the voice path for a phone call doesn't need the
> CPU to do anything. It's probably best to view a phone as a bunch of
> interconnected systems that happen to sit in the same box, and there's
> various design decisions that can be taken about which systems own the
> shared components.
OK, apologies, I thought you were talking about the wait-for-a-call case.
If there actually is a call ongoing, then the user perceives the system as
doing something, so this is similar to audio playback and quite different
from wake-on-LAN or system monitoring.
Thanx, Paul
On Aug 7, 2010, at 5:11 AM, Rafael J. Wysocki wrote:
> But in principle that need not mean suspending the entire system.
> To get applications out of the way, you need to freeze user space.
> However, that's not sufficient, because in addition to that you need to
> prevent deactivate the majority of interrupt sources to avoid waking up the
> CPU (from C-states) too often.
True, but again, consider the MacBook. If you plug in an iPod, the machine will wake up for *just* long enough to let the iTunes sync the iPod, but once its done, the machine goes back to sleep again immediately. I doubt MacOS has something called a "suspend blocker" which prevents the machine from sleeping until iTunes finished, which when released, allows the machine to suspend again immediately. But neither did I see any evidence that it took 30 seconds for some kludgy polling process to decide that iTunes was done, and to allow the MacBook to go back to sleep. Clearly, the MacBook allows some interrupts through, and some USB insert events through, but clearly not all. (Inserting a USB drive doesn't wake up the laptop; at least, not for long.)
Can we do something as smooth with a Linux desktop? And if not, why not? (Oh yeah, and wasn't this supposed to be the year of the Linux Desktop? :-)
-- Ted
On Sat, Aug 07, 2010 at 03:00:48AM -0700, [email protected] wrote:
> On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
>
> >On Saturday, August 07, 2010, [email protected] wrote:
> >>On Sat, 7 Aug 2010, Mark Brown wrote:
> >>
> >>>On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
> >>>>On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> >...
> >>What we want to have happen in an ideal world is
> >>
> >>when the storage isn't needed (between reads) the storage should shutdown
> >>to as low a power state as possible.
> >>
> >>when the CPU isn't needed (between decoding bursts) the CPU and as much of
> >>the system as possible (potentially including some banks of RAM) should
> >>shutdown to as low a power state as possible.
> >
> >Unfortunately, the criteria for "not being needed" are not really
> >straightforward and one of the wakelocks' roles is to work around this issue.
>
> if you can ignore the activity caused by the other "unimportant"
> processes in the system, why is this much different then just the
> one process running, in which case standard power management sleeps
> work pretty well.
But isn't the whole point of wakelocks to permit developers to easily
and efficiently identify which processes are "unimportant" at a given
point in time, thereby allowing them to be ignored?
I understand your position -- you believe that PM-driving applications
should be written to remain idle any time that they aren't doing something
"important". This is a reasonable position to take, but it is also
reasonable to justify your position. Exactly -why- is this better?
Here is my evaluation:
o You might not need suspend blockers. This is not totally clear,
and won't be until you actually build a system based
on your design.
o You will be requiring that developers of PM-driving applications
deal with more code that must be very carefully coded and
validated. This requirement forces the expenditure of lots
of people time to save a very small amount of very inexpensive
memory (that occupied by the suspend-blocker code).
Keep in mind that there was a similar decision in the -rt kernel.
One choice was similar to your proposal: all code paths must call
schedule() sufficiently frequently. The other choice was to allow
almost all code paths to be preempted, which resembles suspend blockers
(preempt_disable() being analogous to acquiring a suspend blocker,
and preempt_enable() being analogous to releasing a suspend blocker).
Then as now, there was much debate. The choice then was preemption.
One big reason was that the choice of preemption reduced the amount of
real-time-aware code from the entire kernel to only that part of the
kernel that disabled preemption, which turned out to greatly simplify
the job of meeting aggressive scheduling-latency goals. This experience
does add some serious precedent against your position. So, what do you
believe is different in the energy-efficiency case?
> >>today there are two ways of this happening, via the idle approach (on
> >>everything except Android), or via suspend (on Android)
> >>
> >>Given that many platforms cannot go to into suspend while still playing
> >>audio, the idle approach is not going to be able to be eliminated (and in
> >>fact will be the most common approach to be used/deugged in terms of the
> >>types of platforms), it seems to me that there may be a significant amount
> >>of value in seeing if there is a way to change Android to use this
> >>approach as well instead of having two different systems competing to do
> >>the same job.
> >
> >There is a fundamental obstacle to that, though. Namely, the Android
> >developers say that the idle-based approach doesn't lead to sufficient energy
> >savings due to periodic timers and "polling applications".
>
> polling applications can be solved by deciding that they aren't
> going to be allowed to affect the power management decision (don't
> consider their CPU useage when deciding to go to sleep, don't
> consider their timers when deciding when to wake back up)
Agreed, and the focus is on how one decides which applications need
to be considered. After all, the activity of a highly optimized
audio-playback application looks exactly like that of a stupid polling
application -- they both periodically consume some CPU. But this is
something that you and the Android guys are actually agreeing about.
You are only arguing about exactly what mechanism should be used to
make this determination. The Android guys want suspend blockers, and
you want to extend cgroups.
So I believe that the next step for you is to implement your approach
so that it can be compared in terms of energy efficiency, code size,
intrusiveness, performance, and compatibility with existing code.
> >Technically that
> >boils down to the interrupt sources that remain active in the idle-based case
> >and that are shut down during suspend. If you found a way to deactivate all of
> >them from the idle context in a non-racy fashion, that would probably satisfy
> >the Android's needs too.
>
> well, we already have similar capibility for other peripherals (I
> keep pointing to drive spin down as an example), the key to avoiding
> the races seems to be in the drivers supporting this.
The difference is that the CPU stays active in the drive spin down
case -- if the drive turns out to be needed, the CPU can spin it up.
The added complication in the suspend case is that the CPU goes away,
so that you must more carefully plan for all of the power-up cases.
> the fact that Android is making it possible for suspend to
> selectivly avoid disabling them makes me think that a lot of the
> work needed to make this happen has probably been done. look at what
> would happen in a suspend if it decided to leave everything else on
> and just disable the one thing, that should e the same thing that
> happens if you are just disabling that one thing for idle sleep.
We already covered the differences between suspend and idle, now
didn't we? ;-)
Thanx, Paul
On Sat, Aug 07, 2010 at 02:38:35AM -0700, [email protected] wrote:
> On Sat, 7 Aug 2010, Ted Ts'o wrote:
>
> >On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
> >>
> >>that description sounds far more like normal sleep power management
> >>that suspending. especially since they want to set timers to wake
> >>the system up and the defining characteristic of suspend (according
> >>to this thread) is that timers don't fire while suspended.
> >>
> >>as I am seeing it, there are two reasons why this don't "just work"
> >>
> >>1. sleeping can't currently save as much power as suspending
> >
> >No, I don't think that's the case at all. The key thing here is that
> >*most* applications don't need to be modified to use suspend locks,
> >because even though they might be in an event loop, when the user user
> >turns off the display, the user generally doesn't want it doing things
> >on their behalf.
> >
> >Again, take for example the Mac Book, since Apple has gotten this
> >right for most users' use cases. When you close the lid, you even if
> >the application is under the misguided belief that it should be
> >checking every five seconds to see whether or not the web page has
> >reloaded --- actually, that's not what you want. You probably want
> >the application to be forcibly put to sleep. So the whole point of
> >the suspend blocker design is that you don't have to modify most
> >applications; they just simply get put to sleep when you close the
> >MacBook lid, or, in the case of the Android device, you push the
> >button that turns off the screen.
>
> this doesn't require wakelocks or anything else new. all it takes is
> setting the policy that you don't want anything to run when the lid
> is closed and a switch to detect the lid being closed. Laptops have
> been doing this for years.
Please re-read Ted's paragraph above, but carefully this time. You will
then see that the desired policy is -not- "you don't want anything to
run when the lid is closed."
> >So the reason why this doesn't work is that power management for small
> >mobile devices *is* different from power management for laptops and
> >data center servers, and if you want a rich application ecosystem,
> >it's best if you don't require them to be specially tuned to use the
> >absolute minimum power. (And that means waking up every 30 seconds
> >might be too much; as Brian and Arve have pointed out, with the G1 in
> >airplane mode, the CPU might be waking up once every half hour or more
> >--- and at that rate, powertop will be waking up the CPU more than
> >Android system would be doing so.)
>
> note that nothing that I have proposed would wake up a sleeping
> system. the 'every several seconds' thing that I proposed was that
> on a system that's fully awake, busy and doesn't want to sleep,
> there would be a context switch periodically by a privilaged process
> so that the system would not end up deciding it was idle and halt
> everything. Now that I think about this more, it's not needed if you
> want to override this to keep everything running for a significant
> amount of time, just change the power saving mode from "sleep if a
> privilaged task isn't running" to "disable suspend". This can be
> done today by changing the right sysfs value. normal privilaged
> processes would never need to do this, only gatekeeper daemons that
> want to let unprivilaged processes run even if no privilaged
> processes want to run would need to do this (i.e. in the current
> system, whatever process controls the screen would probably be
> right)
>
> >So the real key here is to take most applications, which may be
> >written using techniques that might be considered well written from a
> >laptop point of view, but not for a cell phone, and not require
> >modifications. Even though the application writer might think it's
> >doing well by waking up every 15 seconds, if the laptop lid is down,
> >or if the screen is off, for **most** applications, it should be
> >forcibly put to sleep.
> >
> >It's only the rare applications that should really be allowed to run
> >while screen is off. And it's only those applications that need
> >modifications to use suspend blocker. From your earlier comments, it
> >seems that this is the key point which you are missing. (No doubt,
> >some of these applications that do need to know about suspend blockers
> >are important ones; ones that make sure the battery isn't about to
> >blow up, or ones which silently wake up every 10-15 minutes to pull
> >down fresh mail for you from your mail server. But those applications
> >are the exception, not the rule.)
>
> the question is what it takes to make an application privilaged like this.
>
> what I proposed was to make it possible for the user/admin to select
> what applications are allowed to keep the system awake.
The Android guys do the same.
> wakelocks require that the application developer decide that they
> want to keep the system awake as well as the user/admin
Whereas you require that the application developer redesign/rewrite
applications to decide when to keep the system awake, e.g., by carefully
determining when to idle themselves. The difference is that the Android
developer need only release a suspend blocker. In contrast, you are
requiring that the developer rewrite all the code that follows the point
where the Android developer would release a suspend blocker.
Your way seems to require that the developer do more work for the
same result. Why?
Now, I do agree that a safe way to freeze the power-oblivious applications
could be valuable, as it might reduce power consumption while the
screen was blanked but while a PM-driving application was holding a
suspend blocker. However, as we have discussed, you have to be very
careful not to freeze any app holding a user-level resource.
> take your example of a mail client waking up every 15 min.
>
> with Android it needs to be privilaged to grab the wakelock while
> fetching the mail, it also needs to use a privilaged API to set the
> wakeups to wake it up at those times.
>
> with what I proposed all you need to do is to tag the application as
> power privilaged and then if the application sleeps for 15 min
> between doing thing the system will wake up every 15 min, work for a
> short time, then go back to sleep.
>
>
> if you want to put everything to sleep when the screen blanks,
> that's trivial to do.
>
> the fun starts when you want to say that there are some things you
> don't want to put to sleep.
Which is in fact a critical requirement that you appear to have been
ignoring in your words above.
> do you let some processes run while halting others?
> in which case how do you prevent deadlocks?
> on the other hand, sleeping again is simple, you sleep when
> there is nothing more to run
> or do you let wasteful processes run while you are awake?
> this avoids deadlocks, but how do you decide when to sleep again?
>
>
> Android approaches this by requiring that any program that a user
> may want to keep running must be modified to use wakelocks.
>
> My suggestion was that the system ignore other processes when
> deciding if the system is idle enough to put to sleep.
But your suggestion seems to require quite a bit more coding effort for
little gain. The Android developer can just release a suspend blocker,
and in contrast, a developer using your proposal needs to rewrite all
the code following the point at which the Android developer released the
suspend blocker. So why are you saying that your is approach better? ;-)
> Yes the Android approach works reasonably well on the phones where
> everything must currently be custom developed anyway (due to screen
> and UI constraints), but as Android starts getting used on laptops
> and other larger devices is that really still the right approach? or
> would it be better to have something that could use standard
> software in the privilaged mode?
>
> to use your example of a mail client, why should someone not be able
> to use fetchmail to get their mail instead of requiring that
> fetchmail be modified to use wavelocks (or a substatute written)?
>
>
>
> the theoretical best approach would probably look nothing like
> either of these. Instead it would probably either
>
> forbid privilaged processes from having blocking dependancies on
> unprivilaged processes (you can then just halt the unprivilaged
> processes when you blank the screen and let idle sleep deal with the
> privilged processes)
>
> or
>
> use something like priority inheritance through userspace so that if
> a privilaged process blocks on something where it's waiting for an
> unprivilaged process, that unprivilaged process gets woken up and
> allowed to run until it unblocks the privilaged process.
>
> both of these have been deemed too hard
And for good reason.
Thanx, Paul
On Sat, 7 Aug 2010, Paul E. McKenney wrote:
> On Sat, Aug 07, 2010 at 03:00:48AM -0700, [email protected] wrote:
>> On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
>>
>>> On Saturday, August 07, 2010, [email protected] wrote:
>>>> On Sat, 7 Aug 2010, Mark Brown wrote:
>>>>
>>>>> On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
>>>>>> On Fri, 6 Aug 2010, Paul E. McKenney wrote:
>>> ...
>>>> What we want to have happen in an ideal world is
>>>>
>>>> when the storage isn't needed (between reads) the storage should shutdown
>>>> to as low a power state as possible.
>>>>
>>>> when the CPU isn't needed (between decoding bursts) the CPU and as much of
>>>> the system as possible (potentially including some banks of RAM) should
>>>> shutdown to as low a power state as possible.
>>>
>>> Unfortunately, the criteria for "not being needed" are not really
>>> straightforward and one of the wakelocks' roles is to work around this issue.
>>
>> if you can ignore the activity caused by the other "unimportant"
>> processes in the system, why is this much different then just the
>> one process running, in which case standard power management sleeps
>> work pretty well.
>
> But isn't the whole point of wakelocks to permit developers to easily
> and efficiently identify which processes are "unimportant" at a given
> point in time, thereby allowing them to be ignored?
>
> I understand your position -- you believe that PM-driving applications
> should be written to remain idle any time that they aren't doing something
> "important". This is a reasonable position to take, but it is also
> reasonable to justify your position. Exactly -why- is this better?
> Here is my evaluation:
>
> o You might not need suspend blockers. This is not totally clear,
> and won't be until you actually build a system based
> on your design.
>
> o You will be requiring that developers of PM-driving applications
> deal with more code that must be very carefully coded and
> validated. This requirement forces the expenditure of lots
> of people time to save a very small amount of very inexpensive
> memory (that occupied by the suspend-blocker code).
the issue isn't avoiding the memory useage, the issue is avoiding the
special API requirement that make the userspace code no longer be
portable.
note that there are a lot of battery powered embedded devices out there
that work just fine without wakelocks. They are able to use the existing
idle/sleep and suspend options to get good battery life.
The key difference is that Android allows other programs to be loaded on
the system, and the current idle/sleep/suspend triggers can't tell the
difference between the important software and the other software.
> Keep in mind that there was a similar decision in the -rt kernel.
> One choice was similar to your proposal: all code paths must call
> schedule() sufficiently frequently. The other choice was to allow
> almost all code paths to be preempted, which resembles suspend blockers
> (preempt_disable() being analogous to acquiring a suspend blocker,
> and preempt_enable() being analogous to releasing a suspend blocker).
>
> Then as now, there was much debate. The choice then was preemption.
> One big reason was that the choice of preemption reduced the amount of
> real-time-aware code from the entire kernel to only that part of the
> kernel that disabled preemption, which turned out to greatly simplify
> the job of meeting aggressive scheduling-latency goals. This experience
> does add some serious precedent against your position. So, what do you
> believe is different in the energy-efficiency case?
for one thing, there was never any thought that any code that would have
to have preempt written would ever run anywhere else other than inside the
linux kernel.
If you had proposed that userspace be allowed to do preempt_enable/disable
calls, it would have been a very different discussion.
In the case of real-time applications, we require that things that are
given real-time priority be carefully coded to behave well, and that if
they depend on things that are not given real-time priority they may not
behave as expected. Priority Inheritance is a way to avoid complete system
lockup in many cases, but it would still be possible for a badly written
real-time app to kill the system if it does something like go into a
busy-loop waiting for a file to be created by a non-real-time process.
wakelocks are like implementing real-time by allowing userspace to issue
preempt_disable() calls to tell the scheduler not to take the CPU away
from them until they make a preempt_enable() call.
In addition wakelocks cannot replace the need to write efficient code. all
that wakelocks do is to prevent the system from doing a suspend, you still
want to have the code written to not do unneccessary wakeups that would
prevent you from using the low-power modes other than suspend. On the
other hand, it _is_ possible for the idle/sleep states to be extended to
also cover suspend.
>>>> today there are two ways of this happening, via the idle approach (on
>>>> everything except Android), or via suspend (on Android)
>>>>
>>>> Given that many platforms cannot go to into suspend while still playing
>>>> audio, the idle approach is not going to be able to be eliminated (and in
>>>> fact will be the most common approach to be used/deugged in terms of the
>>>> types of platforms), it seems to me that there may be a significant amount
>>>> of value in seeing if there is a way to change Android to use this
>>>> approach as well instead of having two different systems competing to do
>>>> the same job.
>>>
>>> There is a fundamental obstacle to that, though. Namely, the Android
>>> developers say that the idle-based approach doesn't lead to sufficient energy
>>> savings due to periodic timers and "polling applications".
>>
>> polling applications can be solved by deciding that they aren't
>> going to be allowed to affect the power management decision (don't
>> consider their CPU useage when deciding to go to sleep, don't
>> consider their timers when deciding when to wake back up)
>
> Agreed, and the focus is on how one decides which applications need
> to be considered. After all, the activity of a highly optimized
> audio-playback application looks exactly like that of a stupid polling
> application -- they both periodically consume some CPU. But this is
> something that you and the Android guys are actually agreeing about.
> You are only arguing about exactly what mechanism should be used to
> make this determination. The Android guys want suspend blockers, and
> you want to extend cgroups.
I want the kernel to be explicitly told that this application is important
(or alternativly that these other applications are not). I suggested
cgroups as a possible way to do this, but anything that could tell the
kernel what processes to care about and what ones to not care about would
work. My initial thought had actually been to do something like echo the
pid of important processes into a /proc or /sys file, but I was under the
impression that there were a lot of processes that would get this state
and therefore a more general tool like cgroups (which as I understand it
automatically puts children of a process into the same cgroup as the
parent) seemed moreuseful
> So I believe that the next step for you is to implement your approach
> so that it can be compared in terms of energy efficiency, code size,
> intrusiveness, performance, and compatibility with existing code.
>
>>> Technically that
>>> boils down to the interrupt sources that remain active in the idle-based case
>>> and that are shut down during suspend. If you found a way to deactivate all of
>>> them from the idle context in a non-racy fashion, that would probably satisfy
>>> the Android's needs too.
>>
>> well, we already have similar capibility for other peripherals (I
>> keep pointing to drive spin down as an example), the key to avoiding
>> the races seems to be in the drivers supporting this.
>
> The difference is that the CPU stays active in the drive spin down
> case -- if the drive turns out to be needed, the CPU can spin it up.
> The added complication in the suspend case is that the CPU goes away,
> so that you must more carefully plan for all of the power-up cases.
I agree tha the power down and restart needs to be planned, but it's not
like you are going to wake up the drive (or the audio hardware0 without
waking up the CPU first.
even with idle sleep modes and drive spin-down there is no provision for
the drive to be restarted if the CPU is asleep, you first have something
happen that wakes up the CPU and it then wakes up the drive. This same
approach should work for other things.
>> the fact that Android is making it possible for suspend to
>> selectivly avoid disabling them makes me think that a lot of the
>> work needed to make this happen has probably been done. look at what
>> would happen in a suspend if it decided to leave everything else on
>> and just disable the one thing, that should e the same thing that
>> happens if you are just disabling that one thing for idle sleep.
>
> We already covered the differences between suspend and idle, now
> didn't we? ;-)
we did, however at the time suspend was to stop everything, now we are
finding that Android has multiple flavors of suspend, one of which stops
everything, the others leave some things running.
David Lang
On Sat, 7 Aug 2010, Theodore Tso wrote:
> On Aug 7, 2010, at 5:11 AM, Rafael J. Wysocki wrote:
>
>> But in principle that need not mean suspending the entire system.
>> To get applications out of the way, you need to freeze user space.
>> However, that's not sufficient, because in addition to that you need to
>> prevent deactivate the majority of interrupt sources to avoid waking up the
>> CPU (from C-states) too often.
> True, but again, consider the MacBook. If you plug in an iPod, the
> machine will wake up for *just* long enough to let the iTunes sync the
> iPod, but once its done, the machine goes back to sleep again
> immediately. I doubt MacOS has something called a "suspend blocker"
> which prevents the machine from sleeping until iTunes finished, which
> when released, allows the machine to suspend again immediately. But
> neither did I see any evidence that it took 30 seconds for some kludgy
> polling process to decide that iTunes was done, and to allow the MacBook
> to go back to sleep.
nobody has proposed a polling process to decide the system can suspend,
what I proposed was to have idle detection decide the system can suspend,
which would mean that if you don't want the system to suspend you have to
do something to keep it from being idle.
At the time I didn't know that Android always disabled suspend for the
entire time the display was on, so I made the assumption that timouts had
to be long enough for input events to keep the system awake, which would
put them on the order of 30 seconds or longer.
If all that is wanted is to disable the suspend for the entire time the
backlight is on you don't need wakelocks, and you don't need a privilaged
thread waking up, all you need is to tell the power management system not
to suspend through the existing mechanism. you could create a new
mechanism (wakelock) to pass the same information, but what is the
advantage of doing so?
David Lang
On Sat, 7 Aug 2010, Alan Stern wrote:
> On Fri, 6 Aug 2010 [email protected] wrote:
>
>>>> 1. the ability to decide to suspend while there are still some
>>>> 'unimportant' apps running.
>>>
>>> While this may be true in some literal sense, it certainly is not the
>>> best way to view the situation. Linux already has the ability to
>>> suspend (or to decide to suspend) whenever you want. What Android has
>>> added is the ability to suspend conditionally, based on whether or not
>>> some applications or drivers want to keep the system running.
>>
>> Ok, aside from possibly drivers, what' stopping this from being done on a
>> valilla system today?
>
> Nothing much. Mainly just the fact that Rafael's code is so new. It
> hasn't yet been integrated into the drivers that should use it.
makes sense.
>>> Furthermore, this statement leaves out the primary purpose of
>>> wakelocks: to avoid races between suspending and wakeup events. And it
>>> also ignores a very important distinction: the difference between
>>> drivers and applications. Wakelocks are used by both, but it has been
>>> shown that only the wakelocks used by drivers need to be implemented in
>>> the kernel -- the others can be implemented entirely in userspace.
>>
>> Ok, this is the first I've heard in this discussion that wakelocks would
>> not be available to userspace. In fact it was explicitly stated that
>> userspace applications called IOCTLs to get/release the wakelock.
>
> Android's wakelock implementation does make wakelocks available to
> userspace. In Rafael's approach there is nothing comparable. Instead
> "userspace wakelock"-equivalents have to be handled by a power manager
> program.
And the question to the Android people is if they consider this acceptable
or think that this means that the vanilla can't support them.
>> many of my objections (voiced in another thread) about Android specific
>> features are not relavent if the wakelock in userspace is just part of
>> that application framework and not tied into the kernel.
>>
>>> All of these issues are addressed by Raphael's new wakeup_events code.
>>
>> Ok, then why is there still discussion about wakelocks at all if Raphael
>> has implemnetd the needed kernel functionality and userspace is Android
>> SDK specific?
>
> This thread started when Paul posted his list of requirements for
> Android power management (or power management in general). It wasn't
> really specific to wakelocks, but people brought them up when
> discussing how those requirements are currently being met.
>
> In fact, it seems to me that _you_ are the person most responsible for
> prolonging this discussion.
I'll admit to that, but it seems like there is still new information
comeing up about the requirements, as well as the current implementation.
>>>> If these two features were available, I think that the rest of what they
>>>> are looking for could be built up without requireing other changes.
>>>
>>> They already _are_ available. Admittedly, only since quite recently.
>>> (Rafael's new code was accepted during the 2.6.36 merge window.)
>>
>> Do Brian and Arve agree that this solves their problem?
>
> I think you should ask them instead of asking me.
Since they are following this thread, this was intended to be asking them
torespond.
>> to be fair, there have been numerous complaints about suspend being
>> separate from deep sleep long before Android. Linus' blow-up that resulted
>> in Hibernation and Suspend being separated from each other is a case in
>> point. He was making the point that there shouldn't be a difference
>> between the deepest sleep and suspend.
>
> This may be controversial, but I think Rafael will agree when I say
> that (in this one respect) Linus was wrong. Separating hibernation
> from suspend makes sense, and I agree that the differences between
> deepest idle and suspend should be minimized. But to get rid of them
> altogether would be wrong (and probably not possible anyway).
if you thing the differences should be minimized, why do you think that
getting rid of them would be wrong?
I know that Rafael disagrees with Linus, because he has not implemented
what Linus suggested.
>> As deep sleep gains the ability to use even less power and as suspend
>> gains the ability to leave things on sometimes, the difference between
>> them is dissapearing. I wouldn't be at all surprised to see them start
>> overlaping soon. So it's not that I think Android should use deep sleeps
>> instead of suspend, but rather that suspend should just be the deepest
>> sleep, one mechanism instead of two.
>
> I disagree. There are critical differences between them:
>
> Suspend uses the freezer and idle doesn't.
>
> Suspend generally forces devices to go into their low-power
> states immediately, whereas idle tends to leave unused devices
> at full power for some time before going to low power (to
> minimize average latency).
this sounds like policy, not capability.
> Overall, suspend generally has longer latency than idle. (This
> varies among platforms.)
even different idle modes have different latency
> The set of wakeup sources (including timers) is different.
I agree that they are different, but don't they also vary within sleep or
suspend as well?
> On some systems, suspend uses platform-specific mechanisms to
> go into lower power states than are available to idle.
the exact mechanism to go into low-power states is platform specific to
start with (there are some very popular platforms admittedly, like the PC
ACPI modes)
as I see it
Sleep
a policy engine to decide when to sleep, how deeply to sleep, what to
disable, what will wake you up (this includes taking into account desired
latency, and the amount of power/time needed to get in and out of the
various modes)
platform specific mechanisms for transitioning in and out of the modes.
Suspend
a policy engine to decide when to suspend, what to leave enabled when you
supend, what will wake you i[
platform specific mechanisms for transition in and out of suspend. I view
use of the freezer to be one of these mechansims.
Somewhere amoung this mess are things like spinning down drives, disabling
inactive network interfaces, etc. I don't knwo if those are run from the
sleep policy engine, or if there is a third policy engine to decide these
things.
why should there be multiple different policy engines making power
management decisions? it seems to me like these policy engines can and
should be merged, with the resulting engine able to trigger all the
existing mechanisms for transitioning between modes.
David Lang
On Sat, Aug 07, 2010 at 01:17:48PM -0700, [email protected] wrote:
> On Sat, 7 Aug 2010, Paul E. McKenney wrote:
>
> >On Sat, Aug 07, 2010 at 03:00:48AM -0700, [email protected] wrote:
> >>On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
> >>
> >>>On Saturday, August 07, 2010, [email protected] wrote:
> >>>>On Sat, 7 Aug 2010, Mark Brown wrote:
> >>>>
> >>>>>On Fri, Aug 06, 2010 at 04:35:59PM -0700, [email protected] wrote:
> >>>>>>On Fri, 6 Aug 2010, Paul E. McKenney wrote:
> >>>...
> >>>>What we want to have happen in an ideal world is
> >>>>
> >>>>when the storage isn't needed (between reads) the storage should shutdown
> >>>>to as low a power state as possible.
> >>>>
> >>>>when the CPU isn't needed (between decoding bursts) the CPU and as much of
> >>>>the system as possible (potentially including some banks of RAM) should
> >>>>shutdown to as low a power state as possible.
> >>>
> >>>Unfortunately, the criteria for "not being needed" are not really
> >>>straightforward and one of the wakelocks' roles is to work around this issue.
> >>
> >>if you can ignore the activity caused by the other "unimportant"
> >>processes in the system, why is this much different then just the
> >>one process running, in which case standard power management sleeps
> >>work pretty well.
> >
> >But isn't the whole point of wakelocks to permit developers to easily
> >and efficiently identify which processes are "unimportant" at a given
> >point in time, thereby allowing them to be ignored?
> >
> >I understand your position -- you believe that PM-driving applications
> >should be written to remain idle any time that they aren't doing something
> >"important". This is a reasonable position to take, but it is also
> >reasonable to justify your position. Exactly -why- is this better?
> >Here is my evaluation:
> >
> >o You might not need suspend blockers. This is not totally clear,
> > and won't be until you actually build a system based
> > on your design.
> >
> >o You will be requiring that developers of PM-driving applications
> > deal with more code that must be very carefully coded and
> > validated. This requirement forces the expenditure of lots
> > of people time to save a very small amount of very inexpensive
> > memory (that occupied by the suspend-blocker code).
>
> the issue isn't avoiding the memory useage, the issue is avoiding
> the special API requirement that make the userspace code no longer
> be portable.
>
> note that there are a lot of battery powered embedded devices out
> there that work just fine without wakelocks. They are able to use
> the existing idle/sleep and suspend options to get good battery
> life.
There certainly are such devices, but their power-optimized software
is highly non-portable, so I fail to see how this example can possibly
support your position. In addition, there are quite a few non-portable
Linux extensions to the user-mode API, so your point would not carry in
any case.
> The key difference is that Android allows other programs to be
> loaded on the system, and the current idle/sleep/suspend triggers
> can't tell the difference between the important software and the
> other software.
But the suspend blockers can, to the Android guys' point. And something
needs to tell the difference. It is not helpful for you to try to hide
from this issue.
> >Keep in mind that there was a similar decision in the -rt kernel.
> >One choice was similar to your proposal: all code paths must call
> >schedule() sufficiently frequently. The other choice was to allow
> >almost all code paths to be preempted, which resembles suspend blockers
> >(preempt_disable() being analogous to acquiring a suspend blocker,
> >and preempt_enable() being analogous to releasing a suspend blocker).
> >
> >Then as now, there was much debate. The choice then was preemption.
> >One big reason was that the choice of preemption reduced the amount of
> >real-time-aware code from the entire kernel to only that part of the
> >kernel that disabled preemption, which turned out to greatly simplify
> >the job of meeting aggressive scheduling-latency goals. This experience
> >does add some serious precedent against your position. So, what do you
> >believe is different in the energy-efficiency case?
>
> for one thing, there was never any thought that any code that would
> have to have preempt written would ever run anywhere else other than
> inside the linux kernel.
Portability is for the common-case power-oblivious applications.
Even on Android, the power-oblivious applications do not need to use
suspend blockers. Suspend blockers are instead used by PM-driving and
power-optimized applications. And as you yourself pointed out in an
earlier email, the PM-driving and power-optimized applications are
in the minority. Furthermore, the suspend-blocker approach allows
the bulk of the code in a PM-driving application to be written in a
power-oblivious manner, greatly easing its implementation while still
providing power-efficient operation.
So again, your point does not carry.
> If you had proposed that userspace be allowed to do
> preempt_enable/disable calls, it would have been a very different
> discussion.
There have been proposals that userspace be allowed to disable preemption,
and the proposals indeed did not get far. However, the Linux user-kernel
API -was- extended to accommodate the underlying need, namely with
futexes. And futexes provide an excellent example of a non-portable
extension to the Linux user-kernel API.
So, sorry, but again, your point does not carry.
> In the case of real-time applications, we require that things that
> are given real-time priority be carefully coded to behave well, and
> that if they depend on things that are not given real-time priority
> they may not behave as expected.
And therefore real-world applications often are designed to minimize the
amount of code that needs real-time privileges, exactly because real-time
code is harder to develop than is non-realtime code. In addition, a
number of Linux-specific facilities have been used to mitigate the
effects of bad behavior by real-time applications.
A similar effect is making itself felt in the power-efficiency arena --
apps minimize the amount of code that must obey the PM-driving rules.
Android suspend blockers are one mechanism to carry this minimization
further.
Easing development of code is something you would do well to take more
seriously.
> Priority Inheritance is a way to
> avoid complete system lockup in many cases, but it would still be
> possible for a badly written real-time app to kill the system if it
> does something like go into a busy-loop waiting for a file to be
> created by a non-real-time process.
Just as it is possible for a badly-designed PM-driving app to kill
the battery. And this is exactly why most apps are power-oblivious, and
further why Android allows PM-driving apps that are not currently holding
suspend blockers to be written in a power-oblivious manner. Doing this
reduces the opportunity for even PM-driving apps to kill the battery.
> wakelocks are like implementing real-time by allowing userspace to
> issue preempt_disable() calls to tell the scheduler not to take the
> CPU away from them until they make a preempt_enable() call.
Not so. Suspend blockers are actually less dangerous than a thread
raising its priority to a real-time level, let alone than the ability
to disable preemption at user level.
> In addition wakelocks cannot replace the need to write efficient
> code. all that wakelocks do is to prevent the system from doing a
> suspend, you still want to have the code written to not do
> unneccessary wakeups that would prevent you from using the low-power
> modes other than suspend.
If you had said "wakelocks cannot -completely- replace the need to write
efficient code", I might agree with you. Just as I would agree that a
compiler cannot -completely- replace the need to write assembly from
time to time. This is no more an argument against suspend blockers
(or something like them) than the occasional need to write assembly is
an argument against compilers.
> On the other hand, it _is_ possible for
> the idle/sleep states to be extended to also cover suspend.
Nice try, but please take a look at any of the prior discussion of how
idle and suspend differ, and then feel free to try again.
> >>>>today there are two ways of this happening, via the idle approach (on
> >>>>everything except Android), or via suspend (on Android)
> >>>>
> >>>>Given that many platforms cannot go to into suspend while still playing
> >>>>audio, the idle approach is not going to be able to be eliminated (and in
> >>>>fact will be the most common approach to be used/deugged in terms of the
> >>>>types of platforms), it seems to me that there may be a significant amount
> >>>>of value in seeing if there is a way to change Android to use this
> >>>>approach as well instead of having two different systems competing to do
> >>>>the same job.
> >>>
> >>>There is a fundamental obstacle to that, though. Namely, the Android
> >>>developers say that the idle-based approach doesn't lead to sufficient energy
> >>>savings due to periodic timers and "polling applications".
> >>
> >>polling applications can be solved by deciding that they aren't
> >>going to be allowed to affect the power management decision (don't
> >>consider their CPU useage when deciding to go to sleep, don't
> >>consider their timers when deciding when to wake back up)
> >
> >Agreed, and the focus is on how one decides which applications need
> >to be considered. After all, the activity of a highly optimized
> >audio-playback application looks exactly like that of a stupid polling
> >application -- they both periodically consume some CPU. But this is
> >something that you and the Android guys are actually agreeing about.
> >You are only arguing about exactly what mechanism should be used to
> >make this determination. The Android guys want suspend blockers, and
> >you want to extend cgroups.
>
> I want the kernel to be explicitly told that this application is
> important (or alternativly that these other applications are not). I
> suggested cgroups as a possible way to do this, but anything that
> could tell the kernel what processes to care about and what ones to
> not care about would work. My initial thought had actually been to
> do something like echo the pid of important processes into a /proc
> or /sys file, but I was under the impression that there were a lot
> of processes that would get this state and therefore a more general
> tool like cgroups (which as I understand it automatically puts
> children of a process into the same cgroup as the parent) seemed
> moreuseful
Again, the Android guys just use a different mechanism. So, as I said
in my earlier email, that the next step for you is to implement your
approach so that it can be compared in terms of energy efficiency, code
size, intrusiveness, performance, and compatibility with existing code.
Please keep in mind that the Android guys really do have code that
works in production, which, despite real and perceived imperfections,
carries serious weight. Rafael and Alan have some code that meets some
but apparently not all of the Android guys' requirements. You have some
serious work to do if you want to catch up to them.
I am sorry, but until you actually have something credible running, I
have to place much more weight on Arve's, Brian's, Rafael's, and Alan's
opinions than on yours.
> >So I believe that the next step for you is to implement your approach
> >so that it can be compared in terms of energy efficiency, code size,
> >intrusiveness, performance, and compatibility with existing code.
> >
> >>>Technically that
> >>>boils down to the interrupt sources that remain active in the idle-based case
> >>>and that are shut down during suspend. If you found a way to deactivate all of
> >>>them from the idle context in a non-racy fashion, that would probably satisfy
> >>>the Android's needs too.
> >>
> >>well, we already have similar capibility for other peripherals (I
> >>keep pointing to drive spin down as an example), the key to avoiding
> >>the races seems to be in the drivers supporting this.
> >
> >The difference is that the CPU stays active in the drive spin down
> >case -- if the drive turns out to be needed, the CPU can spin it up.
> >The added complication in the suspend case is that the CPU goes away,
> >so that you must more carefully plan for all of the power-up cases.
>
> I agree tha the power down and restart needs to be planned, but it's
> not like you are going to wake up the drive (or the audio hardware0
> without waking up the CPU first.
On servers, desktops, and laptops, agreed. In contrast, the embedded
guys have facilities that allows hardware to activate without the CPU
being active at the time. So there is a difference.
> even with idle sleep modes and drive spin-down there is no provision
> for the drive to be restarted if the CPU is asleep, you first have
> something happen that wakes up the CPU and it then wakes up the
> drive. This same approach should work for other things.
It will indeed work, but it can be quite energy inefficient, given the
capabilities of embedded hardware.
> >>the fact that Android is making it possible for suspend to
> >>selectivly avoid disabling them makes me think that a lot of the
> >>work needed to make this happen has probably been done. look at what
> >>would happen in a suspend if it decided to leave everything else on
> >>and just disable the one thing, that should e the same thing that
> >>happens if you are just disabling that one thing for idle sleep.
> >
> >We already covered the differences between suspend and idle, now
> >didn't we? ;-)
>
> we did, however at the time suspend was to stop everything, now we
> are finding that Android has multiple flavors of suspend, one of
> which stops everything, the others leave some things running.
Suspend never has stopped the time-of-day clock, so Android's approach
is nothing new. Besides, in the embedded world, the ability to leave
other types of hardware running during a suspend long predates Android.
It might well be new to you, but it is not at all new.
Thanx, Paul
On Sat, 7 Aug 2010, Paul E. McKenney wrote:
> On Sat, Aug 07, 2010 at 02:38:35AM -0700, [email protected] wrote:
>> On Sat, 7 Aug 2010, Ted Ts'o wrote:
>>
>>> On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
>>
>>> So the real key here is to take most applications, which may be
>>> written using techniques that might be considered well written from a
>>> laptop point of view, but not for a cell phone, and not require
>>> modifications. Even though the application writer might think it's
>>> doing well by waking up every 15 seconds, if the laptop lid is down,
>>> or if the screen is off, for **most** applications, it should be
>>> forcibly put to sleep.
>>>
>>> It's only the rare applications that should really be allowed to run
>>> while screen is off. And it's only those applications that need
>>> modifications to use suspend blocker. From your earlier comments, it
>>> seems that this is the key point which you are missing. (No doubt,
>>> some of these applications that do need to know about suspend blockers
>>> are important ones; ones that make sure the battery isn't about to
>>> blow up, or ones which silently wake up every 10-15 minutes to pull
>>> down fresh mail for you from your mail server. But those applications
>>> are the exception, not the rule.)
>>
>> the question is what it takes to make an application privilaged like this.
>>
>> what I proposed was to make it possible for the user/admin to select
>> what applications are allowed to keep the system awake.
>
> The Android guys do the same.
>
>> wakelocks require that the application developer decide that they
>> want to keep the system awake as well as the user/admin
>
> Whereas you require that the application developer redesign/rewrite
> applications to decide when to keep the system awake, e.g., by carefully
> determining when to idle themselves. The difference is that the Android
> developer need only release a suspend blocker. In contrast, you are
> requiring that the developer rewrite all the code that follows the point
> where the Android developer would release a suspend blocker.
>
> Your way seems to require that the developer do more work for the
> same result. Why?
portability, and the fact that it will save more power even when the
system is prevented from suspending.
>> take your example of a mail client waking up every 15 min.
>>
>> with Android it needs to be privilaged to grab the wakelock while
>> fetching the mail, it also needs to use a privilaged API to set the
>> wakeups to wake it up at those times.
>>
>> with what I proposed all you need to do is to tag the application as
>> power privilaged and then if the application sleeps for 15 min
>> between doing thing the system will wake up every 15 min, work for a
>> short time, then go back to sleep.
>>
>>
>> if you want to put everything to sleep when the screen blanks,
>> that's trivial to do.
>>
>> the fun starts when you want to say that there are some things you
>> don't want to put to sleep.
>
> Which is in fact a critical requirement that you appear to have been
> ignoring in your words above.
I admit that the way I wrote this is confusing, but I don't think I am
ignoring this requirement. the example above was how an application that
the system is not wanting to put to sleep would run with the two
mechansims.
>> do you let some processes run while halting others?
>> in which case how do you prevent deadlocks?
>> on the other hand, sleeping again is simple, you sleep when
>> there is nothing more to run
>> or do you let wasteful processes run while you are awake?
>> this avoids deadlocks, but how do you decide when to sleep again?
>>
>>
>> Android approaches this by requiring that any program that a user
>> may want to keep running must be modified to use wakelocks.
>>
>> My suggestion was that the system ignore other processes when
>> deciding if the system is idle enough to put to sleep.
>
> But your suggestion seems to require quite a bit more coding effort for
> little gain. The Android developer can just release a suspend blocker,
> and in contrast, a developer using your proposal needs to rewrite all
> the code following the point at which the Android developer released the
> suspend blocker. So why are you saying that your is approach better? ;-)
no, the coder needs to make his code not do unnessasary things. Even with
a wakelock this is needed for the system to be able to use lower power
modes while the system is not going to do a suspend anyway.
I am say that if the coder does that, the coder should not also have to
code in wakelocks.
I want it to be as easy as possible to port applications between mobile
platforms. On most platforms wakelocks are not needed because standard
idle/sleep/suspend mechanisms are good enough. Android allows other
applications to run that confuse the idle/sleep/suspend mechanisms, so
something needs to be done to cut through the confusion. Android does this
by creating a new API to control this, I'm suggesting that there should be
a way to tell the system to ignore the other applications so that the
existing mechanisms can make good decisions again.
David Lang
On Sat, Aug 7, 2010 at 1:54 AM, Paul E. McKenney
<[email protected]> wrote:
> o "Ill-behaved application" AKA "untrusted application" AKA
> "crappy application".
> o "PM-driving application" are applications that are permitted
> to acquire suspend blockers on Android.
These definitions are wrong.
1) There are trusted applications that misbehave (the user clicks Yes
when asked about PM permissions)
2) There are untrusted applications that are power optimized (The user
clicks No)
The proponents of suspend blockers in user-space have tried to ignore
this fact, but the truth is that PM permissions and power optimization
are orthogonal to each other.
--
Felipe Contreras
On Sat, Aug 7, 2010 at 9:15 AM, Ted Ts'o <[email protected]> wrote:
> On Fri, Aug 06, 2010 at 08:14:09PM -0700, [email protected] wrote:
>> 1. sleeping can't currently save as much power as suspending
>
> No, I don't think that's the case at all. The key thing here is that
> *most* applications don't need to be modified to use suspend locks,
> because even though they might be in an event loop, when the user user
> turns off the display, the user generally doesn't want it doing things
> on their behalf.
You are overgeneralizing; there are many applications that run in the
background, and you want to keep them running even when the display is
off.
You seen to be concentrating on UI-only applications, for those it's
worth noting that Android provides separate mechanisms for power
saving. Since Android doesn't have true multi-tasking, the
applications must serialize their states so that the next time they
are opened they seem to have not been closed. So, the current active
UI application can be closed while turning off the display, and
re-opened later.
User-space suspend blockers are relevant for background services, and
as it has been discussed before; suspend blockers (not activating
them) might actually degrade power usage.
--
Felipe Contreras
On Sat, Aug 7, 2010 at 9:28 AM, Ted Ts'o <[email protected]> wrote:
> On Fri, Aug 06, 2010 at 06:00:34PM -0700, [email protected] wrote:
>>
>> today there are two ways of this happening, via the idle approach
>> (on everything except Android), or via suspend (on Android)
>
> Most other devices use a lot more power at idle; in some cases it's
> because the hardware just isn't as power optimized (why bother, when
> you have 94,000 mWh of power at your disposal with a 6 cell laptop
> battery, as opposed to the 800-1000 mWh that you might have on a cell
> phone battery). In other cases, it's because the kernel and the
> low-level software stack (never mind the applications) are waking up
> the CPU too darned often --- in other words, idle simply isn't idle
> enough.
>
> So you may want to consider whether part of the problem is that
> general purpose Linux systems need a radical redesign to get power
> utilization down to those sorts of levels --- where the CPU might only
> be waking up once every half-hour or so, and then only do actual
> useful work.
>
> Can you get there by assuming that every single application is
> competently written? In an idle approach, you have to. That way lies
> Maemo, where installing just one bad application will cut your battery
> life time by a factor of 2-3.
Exactly the same happens on Android.
Install one bad application, a request for PM permissions is made, you
click Yes. There's no difference at all.
> You could try stopping processes by
> using kill -STOP, but this at that point, you've moved into Android
> strategy of "suspend". And the only question is what is the most
> efficient way to allow the system to run when there is true work that
> needs to be done, and how to avoid deadlocks by stopping processes
> that might be holding user space locks --- and to administer when and
> how to suspend the processes.
No. You are assuming that PM permissions will be magically set
appropriately; that's not the case.
1) Install a bad application that requests PM permissions and is granted those
In this case you've gained nothing with user-space suspend blockers.
2) Install a good application that is not requesting PM permissions
(or is denied them)
Imagine this application requires expensive initialization, but
afterwards it only needs to send a small packet each minute to a
server. If this application forgets to request PM permission (or is
denied them), then it might miss the 1 minute mark, and would have to
re-initialize when a trusted app starts some work.
In this case suspend blockers cause more battery drain (and the
application to behave poorly).
There's only one case when suspend blockers might actually help:
a) The application is badly written (most probably a UI app drawing
when it shouldn't, which incidentally is not a problem in Android
since it's not multi-tasking)
b) The application is either not requesting, or denied PM permissions
c) The application is not affected too badly if it's not running all
the time (piggy-backing on trusted apps is ok)
For that it's much better to have a different strategy: all
applications are trusted, bad applications must be manually tagged.
Also, instead of having each and every user figure out which are the
bad apps, such information is more pertinent in the app store, where
users could vote when an app is bad PM-use or not; crowd-sourcing the
problem.
But guess what; once you have an app store system that can detect when
an application is badly written, why would you expose the users to
such bad apps?
In Maemo, 3rd party applications have to go trough a community review
(maemo.org extras testing) before they go into the main repository,
and this way bad applications (functionality or PM-wise) don't make it
to the general public.
Also, on mobile phones in general there are 3 kinds of applications.
1) desktop widgets: by far the ones with the most danger of drawing the battery
2) foreground UI apps: also have some danger, but only on
multi-tasking systems (not Android)
3) background services: usually don't do unnecessary work
Suspend blockers are mostly useful for 1), but desktop widgets are
platform-specific, so they are written for embedded anyway, and if you
are writing for embedded, there's no point in relying on
suspend-blockers; just write it PM optimized.
--
Felipe Contreras
On Sat, 7 Aug 2010 [email protected] wrote:
> > This may be controversial, but I think Rafael will agree when I say
> > that (in this one respect) Linus was wrong. Separating hibernation
> > from suspend makes sense, and I agree that the differences between
> > deepest idle and suspend should be minimized. But to get rid of them
> > altogether would be wrong (and probably not possible anyway).
>
> if you thing the differences should be minimized, why do you think that
> getting rid of them would be wrong?
Actually I meant that _attempting_ to get rid of them would be wrong,
because it would be a futile attempt to carry out an impossible task.
> >> As deep sleep gains the ability to use even less power and as suspend
> >> gains the ability to leave things on sometimes, the difference between
> >> them is dissapearing. I wouldn't be at all surprised to see them start
> >> overlaping soon. So it's not that I think Android should use deep sleeps
> >> instead of suspend, but rather that suspend should just be the deepest
> >> sleep, one mechanism instead of two.
> >
> > I disagree. There are critical differences between them:
> >
> > Suspend uses the freezer and idle doesn't.
> >
> > Suspend generally forces devices to go into their low-power
> > states immediately, whereas idle tends to leave unused devices
> > at full power for some time before going to low power (to
> > minimize average latency).
>
> this sounds like policy, not capability.
It isn't. Suspend does not have the capability to leave a device at
full power for 100 ms and then switch it to low power if it hasn't been
used in that time. (Or, it requires special hardware support to be
able to do this.) Idle does have this capability.
> > Overall, suspend generally has longer latency than idle. (This
> > varies among platforms.)
>
> even different idle modes have different latency
But the difference between idle and suspend can be orders of magnitude
larger. That makes it qualitatively different, not just quantitatively
different.
> > The set of wakeup sources (including timers) is different.
>
> I agree that they are different, but don't they also vary within sleep or
> suspend as well?
Suspend _is_ a form of sleep. (The other form is hibernation.) It's
true that the set of wakeup sources can be customized to some extent.
But in the usual implementations, timers are never a wakeup source for
suspend whereas they always are for idle.
> > On some systems, suspend uses platform-specific mechanisms to
> > go into lower power states than are available to idle.
>
> the exact mechanism to go into low-power states is platform specific to
> start with (there are some very popular platforms admittedly, like the PC
> ACPI modes)
Sure, the mechanism is platform-specific. That doesn't change the fact
that ACPI systems can achieve lower power usage with suspend than they
can with idle.
> as I see it
>
> Sleep
Do you mean "idle" or "deep-idle" rather than "sleep"?
> a policy engine to decide when to sleep, how deeply to sleep, what to
> disable, what will wake you up (this includes taking into account desired
> latency, and the amount of power/time needed to get in and out of the
> various modes)
>
> platform specific mechanisms for transitioning in and out of the modes.
>
>
> Suspend
>
> a policy engine to decide when to suspend, what to leave enabled when you
> supend, what will wake you i[
Suspend is initiated entirely by userspace, not by the kernel.
Wakelocks provide a means for the kernel to delay or cancel a suspend
request, not to initiate one.
> platform specific mechanisms for transition in and out of suspend. I view
> use of the freezer to be one of these mechansims.
The freezer is not platform specific.
> Somewhere amoung this mess are things like spinning down drives, disabling
> inactive network interfaces, etc. I don't knwo if those are run from the
> sleep policy engine, or if there is a third policy engine to decide these
> things.
>
>
> why should there be multiple different policy engines making power
> management decisions? it seems to me like these policy engines can and
> should be merged, with the resulting engine able to trigger all the
> existing mechanisms for transitioning between modes.
There are multiple policy engines because one of them is in the kernel
and the other is in userspace. I don't see how you can merge the two.
Alan Stern
On Sun, Aug 08, 2010 at 03:53:52PM +0300, Felipe Contreras wrote:
>
> You are overgeneralizing; there are many applications that run in the
> background, and you want to keep them running even when the display is
> off.
Really? How many do you really expect will be running at the same
time on a mobile platform with a 800-1000 mWh battery? And what
percentage of the applications that might be in a Android or Moblin or
Maemo app store will have things running in the background? 10%?
20%? 50%? 80%?
> You seen to be concentrating on UI-only applications, for those it's
> worth noting that Android provides separate mechanisms for power
> saving. Since Android doesn't have true multi-tasking, the
> applications must serialize their states so that the next time they
> are opened they seem to have not been closed. So, the current active
> UI application can be closed while turning off the display, and
> re-opened later.
Actually in practice, the process or processes which comprise current
active UI application generally won't actually be killed when you turn
off the display. It *might* happen, if one of the rare backround
applications needs more memory than is available without closing some
of the more recently open applications. In practice, the last 2-3
most recently used applications are still loaded in memory so you can
switch back and forth between them simply and easily. It is true they
have to be ready to be killed at any time in case their memory is
needed for the currently active application, but that generally does't
happen right away. The design is to keep this transparent to the user
so the user does't have to keep track of how many apps currently
running on the system.
In any case, the key thing to keep in mind is that when you deal with
extreme power savings, very often you end up making compromises that
probably make sense for other reasons anyway (such as the small screen
size). It's not at all clear that supporting generalized
multi-tasking applications makes sense just from a screen real-estate
issue and user experience POV, never mind battery lifetime.
> User-space suspend blockers are relevant for background services, and
> as it has been discussed before; suspend blockers (not activating
> them) might actually degrade power usage.
Yes, absolutely. Note though that with the iPhone, Apple has decided
that the only background services that will be allowed is audio, VOIP,
location/navigation, and push notifications. iOS developers don't get
access to anything else, and the argument is that nothing else is
really *needed*. Android is more flexible in that it allows for
non-Apple developers to create new background services, but it's not
clear how many you really *need*.
This goes back to your first assertion that there are *many*
applications that need to run in the background. I just don't think
that's true. There will be a few, and probably more than just the
restricted set allowed (and programmed) by Apple. But not *many*.
- Ted
P.S. Although you won't see Apple admitting it, their "fast app
switching" is basically what Android has had all along, and most
mobile developers are quite happy to call this multi-tasking. Yes,
it's not the same as trying to compile the kernel using "make -j 16"
in the background. But are you really going to do that on a cell
phone battery? I think not.
On Sun, Aug 08, 2010 at 04:35:13PM +0300, Felipe Contreras wrote:
> appropriately; that's not the case.
>
> 1) Install a bad application that requests PM permissions and is granted those
>
> In this case you've gained nothing with user-space suspend blockers.
It's clearly possible for a pathological Android application to destroy
the power management policy. But to do that, the author would have to
explicitly take a wakelock. That's difficult to do by accident. The
various failure modes that exist in a non-wakelock world can be
triggered in a wide variety of ways by accident. A sufficiently
reductionist viewpoint will equate the two situations, but in the real
world they're clearly different.
--
Matthew Garrett | [email protected]
On Sat, Aug 07, 2010 at 10:46:59AM -0400, Theodore Tso wrote:
> True, but again, consider the MacBook. If you plug in an iPod, the
> machine will wake up for *just* long enough to let the iTunes sync the
> iPod, but once its done, the machine goes back to sleep again
> immediately. I doubt MacOS has something called a "suspend blocker"
> which prevents the machine from sleeping until iTunes finished, which
> when released, allows the machine to suspend again immediately. But
> neither did I see any evidence that it took 30 seconds for some kludgy
> polling process to decide that iTunes was done, and to allow the
> MacBook to go back to sleep. Clearly, the MacBook allows some
> interrupts through, and some USB insert events through, but clearly
> not all. (Inserting a USB drive doesn't wake up the laptop; at least,
> not for long.)
On the contrary, I suspect that it's precisely equivalent to userspace
suspend blockers. There's no way to conditionalise USB wakeups - the
system comes up when you plug or unplug any USB device. The system is
then fully awake and I'd *guess* that ipods are magically exempted in
some way, with itunes sending a signal when it's complete in order to
allow the suspend policy daemon to trigger a suspend again.
> Can we do something as smooth with a Linux desktop? And if not, why
> not? (Oh yeah, and wasn't this supposed to be the year of the Linux
> Desktop? :-)
gnome-power-manager supports applications inhibiting suspend, but right
now I suspect that it'll never deal with the case where you resume with
the lid closed. It's a simple matter of coding, though.
--
Matthew Garrett | [email protected]
On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <[email protected]> wrote:
> On Sun, Aug 08, 2010 at 04:35:13PM +0300, Felipe Contreras wrote:
>
>> appropriately; that's not the case.
>>
>> 1) Install a bad application that requests PM permissions and is granted those
>>
>> In this case you've gained nothing with user-space suspend blockers.
>
> It's clearly possible for a pathological Android application to destroy
> the power management policy. But to do that, the author would have to
> explicitly take a wakelock. That's difficult to do by accident.
The writer can take a wakelock the whole time the application is
running (isn't that the typical case?), because perhaps the author
realizes that way the application works correctly, or he copy-pasted
it from somewhere else.
--
Felipe Contreras
On Sun, Aug 08, 2010 at 08:08:33PM +0300, Felipe Contreras wrote:
> On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <[email protected]> wrote:
> > It's clearly possible for a pathological Android application to destroy
> > the power management policy. But to do that, the author would have to
> > explicitly take a wakelock. That's difficult to do by accident.
>
> The writer can take a wakelock the whole time the application is
> running (isn't that the typical case?), because perhaps the author
> realizes that way the application works correctly, or he copy-pasted
> it from somewhere else.
No, that's not the typical case.
--
Matthew Garrett | [email protected]
On Saturday, August 07, 2010, Alan Stern wrote:
> On Sat, 7 Aug 2010, Rafael J. Wysocki wrote:
>
> > > Arguably not every PCI interrupt should be regarded as a wakeup event, so
> > > I think we can simply say in the cases when that's necessary the driver should
> > > be responsible for using pm_wakeup_event() or pm_stay_awake() / pm_relax() as
> > > appropriate.
> > >
> > > My patch only added it to the bus-level code which covered the PME-based
> > > wakeup events that _cannot_ be handled by device drivers.
>
> In other words, your bus-level changes were a necessary but not
> sufficient start. I can buy that.
>
> > Also please note that it depends a good deal on the definition of a "wakeup
> > event". Under the definition used when my patch was being developed, ie. that
> > wakeup events are the events that would wake up the system from a sleep state,
> > PCI interrupts cannot be wakeup events, unless the given device remains in the
> > full power state although the system has been suspended (standard PCI devices
> > are not allowed to generate signals except for PME from low-power states).
>
> Um, what do you mean by "event"? Let's take a concrete example.
> Suppose you have a system where you want USB plug or unplug events to
> cause a wakeup. This is relevant to the discussion at hand if your USB
> host controller is a PCI device.
>
> By your reckoning, a plug or unplug event that occurs while the system
> is asleep would be a wakeup event by definition. And yet you say that
> the same plug or unplug event occurring while the controller was at
> full power would not count as a wakeup event? And in particular, it
> should not prevent the system from suspending before the event can be
> fully processed? That doesn't make sense. The same event is the same
> event, regardless of the context in which it occurs. If it is treated
> as a wakeup event in context then it should be treated as a wakeup
> event in other contexts too.
In this example the event is not a PCI interrupt itself, which is a consqeuence
of the event, but the USB plug-unplug. So, whoever detects the plug-unplug
should use pm_stay_awake() or pm_wakeup_event(). That may be an
interrupt handler of a PCI USB controller, so if that is the case, the
controller driver probably should use one of these functions in its interrupt
handler. Still, that by no measn implies that _every_ PCI interrupt should in
principle be regarded as a wakeup event.
Thanks,
Rafael
On Sun, Aug 8, 2010 at 6:57 PM, Ted Ts'o <[email protected]> wrote:
> On Sun, Aug 08, 2010 at 03:53:52PM +0300, Felipe Contreras wrote:
>>
>> You are overgeneralizing; there are many applications that run in the
>> background, and you want to keep them running even when the display is
>> off.
>
> Really? How many do you really expect will be running at the same
> time on a mobile platform with a 800-1000 mWh battery? And what
> percentage of the applications that might be in a Android or Moblin or
> Maemo app store will have things running in the background? 10%?
> 20%? 50%? 80%?
At any given time most of the applications are running on the
background, how much exactly depends on the platform. In my N900 I can
see that at least 90% of the process are running on the background
right now.
>> You seen to be concentrating on UI-only applications, for those it's
>> worth noting that Android provides separate mechanisms for power
>> saving. Since Android doesn't have true multi-tasking, the
>> applications must serialize their states so that the next time they
>> are opened they seem to have not been closed. So, the current active
>> UI application can be closed while turning off the display, and
>> re-opened later.
>
> Actually in practice, the process or processes which comprise current
> active UI application generally won't actually be killed when you turn
> off the display. It *might* happen, if one of the rare backround
> applications needs more memory than is available without closing some
> of the more recently open applications. In practice, the last 2-3
> most recently used applications are still loaded in memory so you can
> switch back and forth between them simply and easily. It is true they
> have to be ready to be killed at any time in case their memory is
> needed for the currently active application, but that generally does't
> happen right away. The design is to keep this transparent to the user
> so the user does't have to keep track of how many apps currently
> running on the system.
My last experience using an Android system was that switching
applications wasn't done "simply and easily".
But supposing it is, Android's UI is completely different to anything
else; you cannot take a GNOME/KDE app and expect it to run on Android.
Since UI applications are written for Android anyway, then they should
be written with PM in mind, and should not rely on suspend blockers.
> In any case, the key thing to keep in mind is that when you deal with
> extreme power savings, very often you end up making compromises that
> probably make sense for other reasons anyway (such as the small screen
> size). It's not at all clear that supporting generalized
> multi-tasking applications makes sense just from a screen real-estate
> issue and user experience POV, never mind battery lifetime.
My guess is you haven't used a truly multi-tasking device like the
N900; now that I've got used to it, I consider that functionality
*essential*.
Multi-tasking and good PM is possible, and the N900 is a good example.
Rather than giving up multi-tasking to see how much longer the battery
can last, I would rather like to see how to improve batter life for
the multi-tasking case.
>> User-space suspend blockers are relevant for background services, and
>> as it has been discussed before; suspend blockers (not activating
>> them) might actually degrade power usage.
>
> Yes, absolutely. Note though that with the iPhone, Apple has decided
> that the only background services that will be allowed is audio, VOIP,
> location/navigation, and push notifications. iOS developers don't get
> access to anything else, and the argument is that nothing else is
> really *needed*. Android is more flexible in that it allows for
> non-Apple developers to create new background services, but it's not
> clear how many you really *need*.
>
> This goes back to your first assertion that there are *many*
> applications that need to run in the background. I just don't think
> that's true. There will be a few, and probably more than just the
> restricted set allowed (and programmed) by Apple. But not *many*.
The argument in favor of suspend blockers is that you could take
applications that are not designed for embedded, and make them run on
an embedded device without draining excessive battery life; those
applications would have to be background services not conflicting with
Android's design.
I agree there probably would not be that many background apps, and
probably even less ported background apps, but that is actually an
argument against suspend blockers.
The rest of the apps (UI apps), cannot be ported, but have to be
written specifically for Android, and therefore should have PM in
mind, and not require suspend blockers to have good power usage.
--
Felipe Contreras
On Sun, Aug 8, 2010 at 10:40 AM, Felipe Contreras
<[email protected]> wrote:
>> This goes back to your first assertion that there are *many*
>> applications that need to run in the background. I just don't think
>> that's true. There will be a few, and probably more than just the
>> restricted set allowed (and programmed) by Apple. But not *many*.
>
> The argument in favor of suspend blockers is that you could take
> applications that are not designed for embedded, and make them run on
> an embedded device without draining excessive battery life; those
> applications would have to be background services not conflicting with
> Android's design.
>
> I agree there probably would not be that many background apps, and
> probably even less ported background apps, but that is actually an
> argument against suspend blockers.
>
> The rest of the apps (UI apps), cannot be ported, but have to be
> written specifically for Android, and therefore should have PM in
> mind, and not require suspend blockers to have good power usage.
I think there's some confusion here.
The default operating mode for Android is to aggressively reach the
lowest possible power state (typically full suspend). suspend
blockers are used by applications to inform the system that they are
currently doing work which requires immediate processing, so the
system will avoid fully suspending until that work is done. You could
think of it as setting your laptop power management settings to be
"blank screen after 60 seconds, power down 5 seconds after blanking",
except that there's also a mechanism for apps to hold off on that
power down if they're doing important work, and a lot more ways to
wakeup beyond opening the lid or pushing the power button.
Straight-forward UI apps don't actually require much special handling
-- it's preferable that they do busy-wait on things, but even when
power is not an issue, wasting cpu spinning needlessly is frowned
upon, so this isn't a special request. There's nothing stopping
somebody from writing an Android app that acts as a bridge to X11 apps
(embedding an X server, etc) and making it possible for native X11
apps to coexist with the Android composition model. I'm a little
surprised nobody has done so, actually. I figured *somebody* would
decide that they like their phone but absolutely need to run xclock or
something locally as a first class app.
The Android app model does say that if you're not in the foreground
(from a UI standpoint) you should save your state, as you may be
terminated if the system runs low on resources. The system only does
this when it has to -- generally when we bottom out on memory. On
devices with sufficient memory, it's quite common for many apps to
remain resident for days-weeks -- I've seen as many as 45-50 apps
running on my nexus one.
I am a little puzzled by the assertion that Android lasks "true
multitasking", but that's another discussion entirely. We certainly
don't lack for many concurrent processes and threads...
Brian
On Sun, Aug 08, 2010 at 03:40:28PM +0300, Felipe Contreras wrote:
> On Sat, Aug 7, 2010 at 1:54 AM, Paul E. McKenney
> <[email protected]> wrote:
> > o ? ? ? "Ill-behaved application" AKA "untrusted application" AKA
> > ? ? ? ?"crappy application".
>
> > o ? ? ? "PM-driving application" are applications that are permitted
> > ? ? ? ?to acquire suspend blockers on Android.
>
> These definitions are wrong.
Indeed they are, given the way you quoted small portions of them. ;-)
> 1) There are trusted applications that misbehave (the user clicks Yes
> when asked about PM permissions)
These would be buggy PM-driving applications. Of course, any type of
application might have bugs, including PM-driving applications.
> 2) There are untrusted applications that are power optimized (The user
> clicks No)
I did indeed exclude this category by saying "power-optimized applications
are those PM-driving applications that have been aggressively tuned
to reduce power consumption." The reason I excluded this case is that
that there are a number of cases where removing the PM-driving attribute
could destroy the power optimization.
If you have an example power-optimized application that retains its
power-optimized property despite lacking PM-driving privileges, please
put it forward. In doing so, please keep two things in mind:
1. The definition of power-optimized is more aggressive than many
people are used to -- look at http://lkml.org/lkml/2010/8/4/409
and search for "POWER-OPTIMIZED APPLICATIONS".
2. In a number of the implementations that do not use suspend blockers,
-all- applications are in effect PM-driving applications.
So it is quite possible that different people are using subtly
different flavors of the "PM-driving applications" definition.
For example, an Android person might consider a application to
be PM-driving only if it is permitted to use suspend blockers,
while a Maemo person might consider an application to be
PM-driving if it had permission to invoke pm_qos functions.
If these two hypothetical people each try to apply their
definition of PM-driving to each others' platforms, they will
likely have severe problems communicating with each other,
right? ;-)
But if you do have a good example, perhaps I will need to change my
definition of power-optimized application.
> The proponents of suspend blockers in user-space have tried to ignore
> this fact, but the truth is that PM permissions and power optimization
> are orthogonal to each other.
In fact, you might have noticed that the proponents of each platform
have been quite persistent in shouting past each other from the warmth
and security of their own particular viewpoints. ;-)
Thanx, Paul
On 8 Aug 2010, at 18:08, Felipe Contreras <[email protected]> wrote:
> On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <[email protected]> wrote:
>> It's clearly possible for a pathological Android application to destroy
>> the power management policy. But to do that, the author would have to
>> explicitly take a wakelock. That's difficult to do by accident.
>
> The writer can take a wakelock the whole time the application is
> running (isn't that the typical case?), because perhaps the author
> realizes that way the application works correctly, or he copy-pasted
> it from somewhere else.
That would be exceptionally unusual. A more common case is that the application will take a wakelock while performing some specific long running task which needs no user intervention such as downloading a file or displaying constantly update status that the user is not expected to respond to. There's no need for applications to take wakelocks while the user is directly interacting with them since the system will be kept awake as a result of the user interaction, the wakelocks are used to override the default suspend that occurs when the user is not interacting with the device.-
On Sun, 8 Aug 2010, Rafael J. Wysocki wrote:
> > > Also please note that it depends a good deal on the definition of a "wakeup
> > > event". Under the definition used when my patch was being developed, ie. that
> > > wakeup events are the events that would wake up the system from a sleep state,
> > > PCI interrupts cannot be wakeup events, unless the given device remains in the
> > > full power state although the system has been suspended (standard PCI devices
> > > are not allowed to generate signals except for PME from low-power states).
> >
> > Um, what do you mean by "event"? Let's take a concrete example.
> > Suppose you have a system where you want USB plug or unplug events to
> > cause a wakeup. This is relevant to the discussion at hand if your USB
> > host controller is a PCI device.
> >
> > By your reckoning, a plug or unplug event that occurs while the system
> > is asleep would be a wakeup event by definition. And yet you say that
> > the same plug or unplug event occurring while the controller was at
> > full power would not count as a wakeup event? And in particular, it
> > should not prevent the system from suspending before the event can be
> > fully processed? That doesn't make sense. The same event is the same
> > event, regardless of the context in which it occurs. If it is treated
> > as a wakeup event in context then it should be treated as a wakeup
> > event in other contexts too.
>
> In this example the event is not a PCI interrupt itself, which is a consqeuence
> of the event, but the USB plug-unplug. So, whoever detects the plug-unplug
> should use pm_stay_awake() or pm_wakeup_event(). That may be an
> interrupt handler of a PCI USB controller, so if that is the case, the
> controller driver probably should use one of these functions in its interrupt
> handler. Still, that by no measn implies that _every_ PCI interrupt should in
> principle be regarded as a wakeup event.
Okay, agreed. I just wanted you to grant that some PCI interrupts
should be treated like wakeup events even if they don't actually wake
the system up from a sleep state. The "PCI interrupts cannot be wakeup
events" statement is a little strong.
Alan Stern
On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> 2010/8/7 Arve Hj?nnev?g <[email protected]>:
> > 2010/8/7 Rafael J. Wysocki <[email protected]>:
> >> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> >>> 2010/8/6 Alan Stern <[email protected]>:
> >>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> ...
> >>> >> total_time, total time the wake lock has been active. This one should
> >>> >> be obvious.
> >>> >
> >>> > Also easily added.
> >>> >
> >>> Only with a handle passed to all the calls.
> >>
> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
> >> mindset. IMHO, it's totally counter productive.
> >>
> >
> > How do you propose to track how long a driver has blocked suspend when
> > you have an unblock call that takes no arguments.
> >
>
> Also, I did not not see a response to my question about why you don't
> want to pass a handle.
It doesn't really matter what I personally want. In fact, I'm not totally
opposed to that idea, although there are disadvantages (eg. a "handle"
would really mean a pointer to an object with certain life cycle that needs to
be managed by the caller and it's not that clear to me who should manage the
objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
example). I sent a pull request for your original patchset to Linus after all. :-)
I said I didn't think "it would fly", meaning that I was afraid the other kernel
developers wouldn't like that change.
The reason why I think so is that you'd like to add a whole new infrastructure
whose only purpose would be debugging that would only be useful to systems
using opportunistic suspend. That, however, is only Android right now and it
cannot use the mainline kernel for other reasons, so basically we would add
infrastructure that's useful to no one.
Thanks,
Rafael
On Sat, 7 Aug 2010, Arve Hj?nnev?g wrote:
> The suspend blockers I added I my suspend blocker patchset were not
> directly associated with a device.
For the benefit of those who don't remember the details of that
patchset, can you list again the suspend blockers/wakelocks that aren't
directly associated with a device? (No need to mention things coming
from userspace -- those are obviously unrelated to any device.)
> The evdev changes could be modified
> to share a device, but it would give less detail since a separate
> queue is created for each client that opens the device.
I don't understand enough about how the input layer works. Does it
create a new queue each time an input device file is opened? And each
input event gets added to all of the queues? And each queue gets a
corresponding wakelock?
If these surmises are right then I can see how relying on devices alone
wouldn't give enough information. There could be two separate programs
both reading input events, and you wouldn't know which one was
responsible for failing to drain its queue.
> The suspend
> blocking work api would have to change so the caller to passes a
> device in, which I think would make that api less flexible.
Maybe. There aren't enough examples coded up yet to be sure. At this
point we could easily make the device argument required instead of
optional, and we could add a device argument to pm_relax.
> Mostly the
> problem is that we need separate stats for wakelocks created by a
> single driver. For instance we will still need a user-space interface
> to block suspend on android devices (lower level services than the
> power manager need to block suspend), with the stats in the device
> struct we have to create a new device for every wakelock user space
> creates in the kernel.
In the scheme we're talking about, the suspend-blocking interface for
uesrspace would be located entirely in the power manager. Hence it
could maintain all the necessary statistics, without involving the
kernel. During early stages of system startup, before the power
manager is running, lower-level services would not be able to block
suspend. This wouldn't matter because at those times the system simply
would not ever suspend -- because suspends have to be initiated by the
power manager.
> There is also the issue of reading the stats. It is a lot easier to
> read a single stats file, than looping though every device on the
> system (when most of the devices never block suspend).
I agree, it should be possible to simplify this and perhaps at the same
time avoid adding all the wakeup-related fields to every device
structure.
> >> > Does Android use any kernel-internal wakelocks both with a timer and
> >> > with active cancellation?
> >> >
> >>
> >> I don't know if they are all kernel-internal but these drivers appear
> >> to use timeouts and active cancellation on the same wakelock:
> >> wifi driver, mmc core, alarm driver, evdev (suspend blocker version
> >> removes the timeout).
Roughly speaking, what do the timings work out to be? That is, how
long are the timeouts for these wakelocks, how long does it usually
take for one of them to be actively cancelled, and what percentage of
them end up timing out?
> >> The wakelock code has an active flag. If we want to keep the
> >> pm_stay_wake nesting (which I would argue against), we would need an
> >> active count. It would also require a handle, which is a change Rafael
> >> said would not fly.
Never mind the handles for now. As for the nesting, we effectively
don't have it when the pm_wakeup_event interface is used. The
pm_stay_awake/pm_relax interface _is_ nested, but since that interface
isn't used anywhere yet, we can't say whether it really should be
nested or not. Maybe we'll find out in the end that it shouldn't be.
Consider an input event queue as a typical case. You would call
pm_stay_awake when an item is added to an empty queue, and you would
call pm_relax when the last item is removed from a queue. The nesting
count would never be > 1, so it wouldn't make any difference either
way.
> >> >> sleep_time, total time the wake lock has been active when the screen was off.
> >> >
> >> > Not applicable to general systems. ?Is there anything like it that
> >> > _would_ apply in general?
> >> >
> >>
> >> The screen off is how it is used on android, the stats is keyed of
> >> what user space wrote to /sys/power/state. If "on" was written the
> >> sleep time is not updated.
I guess we could keep track of pm_stay_awake or pm_wakeup_event calls
made between a read and write of /sys/power/wakeup_count (i.e., while
events_check_enabled is set). Would that be roughly equivalent?
> >> The merged user space interface makes this unclear to me. When I first
> >> used suspend on android I had a power manager process that opened all
> >> the input devices and reset a screen off timeout every time there was
> >> an input event. If the input layer uses pm_stay_awake to block suspend
> >> when the queue is not empty, this will deadlock with the current
> >> interface since reading the wake count will block forever if an input
> >> event occurred right after the power manager decides to suspend.
> >
> > No, in that case suspend will be aborted, IIUC.
> >
>
> How? Your pm_get_wakeup_count function loops until events_in_progress becomes 0.
The problem is that the same task is reading /sys/power/wakeup_count
(thus waiting for an input event queue to drain) and also reading an
input event queue. Clearly this will result in deadlock, but there
must be a reasonably simple way around it. For example, carry out
those two activities in separate threads.
Alan Stern
On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> 2010/8/7 Rafael J. Wysocki <[email protected]>:
> > On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> >> 2010/8/6 Alan Stern <[email protected]>:
> >> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> >> >
> >> >> count, tells you how many times the wakelock was activated. If a
> >> >> wakelock prevented suspend for a long time a large count tells you it
> >> >> handled a lot of events while a small count tells you it took a long
> >> >> time to process the events, or the wakelock was not released properly.
> >> >
> >> > As noted, we already have this.
> >> >
> >>
> >> Almost. We have it when a device is passed in.
> >
> > Sure. And what are the other cases (details, please)?
> >
>
> The suspend blockers I added I my suspend blocker patchset were not
> directly associated with a device. The evdev changes could be modified
> to share a device, but it would give less detail since a separate
> queue is created for each client that opens the device.
OK, that's a good argument.
> The suspend blocking work api would have to change so the caller to passes
> a device in, which I think would make that api less flexible. Mostly the
> problem is that we need separate stats for wakelocks created by a
> single driver. For instance we will still need a user-space interface
> to block suspend on android devices (lower level services than the
> power manager need to block suspend), with the stats in the device
> struct we have to create a new device for every wakelock user space
> creates in the kernel.
Well, what about managing these stats in user space?
> There is also the issue of reading the stats. It is a lot easier to
> read a single stats file, than looping though every device on the
> system (when most of the devices never block suspend).
It seems you can have a list of the "interesting" ones.
> >> >> expire_count, tells you how many times the timeout expired. For the
> >> >> input event wakelock in the android kernel (which has a timeout) an
> >> >> expire count that matches the count tells you that someone opened an
> >> >> input device but is not reading from it (this has happened several
> >> >> times).
> >> >
> >> > This is a little tricky. Rafael's model currently does not allow
> >> > wakeup events started by pm_wakeup_event() to be cancelled any way
> >> > other than by having their timer expire. This essentially means that
> >> > for some devices, expire_count will always be the same as count and for
> >> > others it will always be 0. To change this would require adding an
> >> > extra timer struct, which could be done (in fact, an earlier version of
> >> > the code included it). It would be nice if we could avoid the need.
> >> >
> >> > Does Android use any kernel-internal wakelocks both with a timer and
> >> > with active cancellation?
> >> >
> >>
> >> I don't know if they are all kernel-internal but these drivers appear
> >> to use timeouts and active cancellation on the same wakelock:
> >> wifi driver, mmc core, alarm driver, evdev (suspend blocker version
> >> removes the timeout).
> >
> > You previously said you didn't need timeouted wakelocks in the kernel, so
> > I guess that was incorrect.
> >
>
> I don't know what you are reffering to. We have always stated that we
> need timeouts in the kernel to pass events through other kernel layers
> that do not use wakelocks (that list is much longer than the list
> above which mixes timeouts and unlock on the same wakelock). The only
> feature we do not use is the timeout feature in the user space
> interface to kernel wakelocks.
Now that's more clear, thanks.
> >> >> wake_count, tells you that this is the first wakelock that was
> >> >> acquired in the resume path. This is currently less useful than I
> >> >> would like on the Nexus One since it is usually "SMD_RPCCALL" which
> >> >> does not tell me a lot.
> >> >
> >> > This could be done easily enough, but if it's not very useful then
> >> > there's no point.
> >> >
> >> It is useful there is no other way to tell what triggered a wakeup,
> >> but it would probably be better to just track wakeup interrupts/events
> >> elsewhere.
> >>
> >> >> active_since, tells you how long a a still active wakelock has been
> >> >> active. If someone activated a wakelock and never released it, it will
> >> >> be obvious here.
> >> >
> >> > Easily added. But you didn't mention any field saying whether the
> >> > wakelock is currently active. That could be added too (although it
> >> > would be racy -- but for detecting unreleased wakelocks you wouldn't
> >> > care).
> >> >
> >>
> >> These are the reported stats, not the fields in the stats structure.
> >> The wakelock code has an active flag. If we want to keep the
> >> pm_stay_wake nesting (which I would argue against), we would need an
> >> active count. It would also require a handle, which is a change Rafael
> >> said would not fly.
> >>
> >> >> total_time, total time the wake lock has been active. This one should
> >> >> be obvious.
> >> >
> >> > Also easily added.
> >> >
> >> Only with a handle passed to all the calls.
> >
> > Well, I'm kind of tired of this "my solution is the only acceptable one"
> > mindset. IMHO, it's totally counter productive.
> >
>
> How do you propose to track how long a driver has blocked suspend when
> you have an unblock call that takes no arguments.
You can extend pm_relax() to take a dev argument and measure the time between
pm_stay_awake() and pm_relax() called for the same device.
> >> >> sleep_time, total time the wake lock has been active when the screen was off.
> >> >
> >> > Not applicable to general systems. Is there anything like it that
> >> > _would_ apply in general?
> >> >
> >>
> >> The screen off is how it is used on android, the stats is keyed of
> >> what user space wrote to /sys/power/state. If "on" was written the
> >> sleep time is not updated.
> >>
> >> >> max_time, longest time the wakelock was active uninterrupted. This
> >> >> used less often, but the battery on a device was draining fast, but
> >> >> the problem went away before looking at the stats this will show if a
> >> >> wakelock was active for a long time.
> >> >
> >> > Again, easily added. The only drawback is that all these additions
> >> > will bloat the size of struct device. Of course, that's why you used
> >> > separately-allocated structures for your wakelocks. Maybe we can
> >> > change to do the same; it seems likely that the majority of device
> >> > structures won't ever be used for wakeup events.
> >> >
> >>
> >> Since many wakelocks are not associated with s struct device we need a
> >> separate object for this anyway.
> >>
> >> >> >> and I would prefer that the kernel interfaces would
> >> >> >> encourage drivers to block suspend until user space has consumed the
> >> >> >> event, which works for the android user space, instead of just long
> >> >> >> enough to work with a hypothetical user space power manager.
> >> >
> >> > Rafael doesn't _discourage_ drivers from doing this. However you have
> >> > to keep in mind that many kernel developers are accustomed to working
> >> > on systems (mostly PCs) with a different range of hardware devices from
> >> > embedded systems like your phones. With PCI devices(*), for example,
> >> > there's no clear point where a wakeup event gets handed off to
> >> > userspace.
> >> >
> >> > On the other hand, there's no reason the input layer shouldn't use
> >> > pm_stay_awake and pm_relax. It simply hasn't been implemented yet.
> >> ...
> >>
> >> The merged user space interface makes this unclear to me. When I first
> >> used suspend on android I had a power manager process that opened all
> >> the input devices and reset a screen off timeout every time there was
> >> an input event. If the input layer uses pm_stay_awake to block suspend
> >> when the queue is not empty, this will deadlock with the current
> >> interface since reading the wake count will block forever if an input
> >> event occurred right after the power manager decides to suspend.
> >
> > No, in that case suspend will be aborted, IIUC.
> >
>
> How? Your pm_get_wakeup_count function loops until events_in_progress becomes 0.
So, to deadlock with it you'd have to call pm_stay_awake() and wait for it to
complete. However, right now there are no means by which user space can call
pm_stay_awake(), so this can't happen.
Of course, if you add pm_stay_awake() to an ioctl() code path, you should make
sure that whoever uses that ioctl() won't be waiting for the power manager to
read from /sys/power/wakeup_count. I guess your point is that this isn't
possible to achieve?
Thanks,
Rafael
On Sun, Aug 08, 2010 at 08:40:28PM +0300, Felipe Contreras wrote:
>
> My guess is you haven't used a truly multi-tasking device like the
> N900; now that I've got used to it, I consider that functionality
> *essential*.
I've used an N800, and I wasn't impressed; if anything, the fact that
I have to worry about manually killing off applications when memory
gets low, I actually thought it was incredibly sucky. It was a
miniature, badly done laptop.
Maybe the N900 is different, but the bigger question is what do you
mean by "multi-tasking"? Definitions are critical here, which is why
Paul was so careful in his definitions section of his document.
Do you mean:
* allowing multiple processes running at the same time?
* allowing some applications to be able to update mail, play audio,
upload location information so your friends know where you are?
* allowing arbitrary applications that users can interact with
simultaneously (which implies a window manager, the need to have
the concept of window focus for keyboard input), etc?
or something else?
> The argument in favor of suspend blockers is that you could take
> applications that are not designed for embedded, and make them run on
> an embedded device without draining excessive battery life; those
> applications would have to be background services not conflicting with
> Android's design.
>
> I agree there probably would not be that many background apps, and
> probably even less ported background apps, but that is actually an
> argument against suspend blockers.
>
> The rest of the apps (UI apps), cannot be ported, but have to be
> written specifically for Android, and therefore should have PM in
> mind, and not require suspend blockers to have good power usage.
If you are using a GUI framework which is optimized for a single-
application-focus-at-a-time UI that isn't GNOME or KDE, then that will
require the applications to be written. However, that's not because
of suspend-blockers.
If you assume a GUI framework which is flexible enough --- maybe Qt
falls into this category, maybe not --- for the rest of the
applications, they don't need to *know* about suspend blockers, and
they certainly do't have to be rewritten or modified specifically for
suspend blockers. So if your argument is that applications that don't
need bacground services (which you've admitted comprises majority of
applicatios) need to be modified or written specifically to support
suspend blockers, that's simply not true. They don't need to be
modified at all.
As far as whether they *should* require suspend blockers to be in the
kernel to get power usage that is suitable for cell phone batteries, I
would agree that in the ideal world, it would be nice if you could
have applications that make the correct performance/battery
utilization tradeoff for devices running on 800 mWh batteries, 94,000
mWh batteries, and while running on the AC mains. But I don't believe
that it's likely to be true, and if you want to try to beat up on
application writers one at a time to be power optimized --- as far as
I'm concerned, that's an argument *for* suspend blockers, since I'm
not big believer in plans that begin, "First, you command the tides of
the sea to go back", King Canute style. :-)
- Ted
2010/8/8 Alan Stern <[email protected]>:
> On Sat, 7 Aug 2010, Arve Hj?nnev?g wrote:
>
>> The suspend blockers I added I my suspend blocker patchset were not
>> directly associated with a device.
>
> For the benefit of those who don't remember the details of that
> patchset, can you list again the suspend blockers/wakelocks that aren't
> directly associated with a device? ?(No need to mention things coming
> from userspace -- those are obviously unrelated to any device.)
Other than the user space interface and the internal main suspend
blocker that patchset modified evdev, and added suspend blocking work.
>
>> The evdev changes could be modified
>> to share a device, but it would give less detail since a separate
>> queue is created for each client that opens the device.
>
> I don't understand enough about how the input layer works. ?Does it
> create a new queue each time an input device file is opened? ?And each
> input event gets added to all of the queues? ?And each queue gets a
> corresponding wakelock?
>
Yes, yes and yes.
> If these surmises are right then I can see how relying on devices alone
> wouldn't give enough information. ?There could be two separate programs
> both reading input events, and you wouldn't know which one was
> responsible for failing to drain its queue.
>
We don't know which one now either since we don't give them unique
names, but we know that one of them is not reading (and it is usually
not the normal input path).
>> The suspend
>> blocking work api would have to change so the caller to passes a
>> device in, which I think would make that api less flexible.
>
> Maybe. ?There aren't enough examples coded up yet to be sure. ?At this
> point we could easily make the device argument required instead of
> optional, and we could add a device argument to pm_relax.
>
I think that would be a good start. I can create dummy devices for now
where I don't already have a device.
>> Mostly the
>> problem is that we need separate stats for wakelocks created by a
>> single driver. For instance we will still need a user-space interface
>> to block suspend on android devices (lower level services than the
>> power manager need to block suspend), with the stats in the device
>> struct we have to create a new device for every wakelock user space
>> creates in the kernel.
>
> In the scheme we're talking about, the suspend-blocking interface for
> uesrspace would be located entirely in the power manager. ?Hence it
> could maintain all the necessary statistics, without involving the
> kernel. ?During early stages of system startup, before the power
> manager is running, lower-level services would not be able to block
> suspend. ?This wouldn't matter because at those times the system simply
> would not ever suspend -- because suspends have to be initiated by the
> power manager.
If we do that, a low level process could try to block suspend while
the power manager is not running. Then the power manager could start
and decide to suspend not knowing that a low level process wanted to
block suspend.
>
>> There is also the issue of reading the stats. It is a lot easier to
>> read a single stats file, than looping though every device on the
>> system (when most of the devices never block suspend).
>
> I agree, it should be possible to simplify this and perhaps at the same
> time avoid adding all the wakeup-related fields to every device
> structure.
>
>> >> > Does Android use any kernel-internal wakelocks both with a timer and
>> >> > with active cancellation?
>> >> >
>> >>
>> >> I don't know if they are all kernel-internal but these drivers appear
>> >> to use timeouts and active cancellation on the same wakelock:
>> >> wifi driver, mmc core, alarm driver, evdev (suspend blocker version
>> >> removes the timeout).
>
> Roughly speaking, what do the timings work out to be? ?That is, how
> long are the timeouts for these wakelocks, how long does it usually
> take for one of them to be actively cancelled, and what percentage of
> them end up timing out?
>
The evdev timeout is a few seconds, and never timeout unless user
space is misbehaving. I don't know how the wifi and mmc wakelocks are
used. The alarm driver uses a 1 or 2 second timeout to abort suspend
when an alarm is set to close to program an rtc alarm. I think this
one is cancelled when the alarm triggers, and the timeout only handles
the case where the client cancelled the alarm before it trigger, but I
don't remember for sure.
>> >> The wakelock code has an active flag. If we want to keep the
>> >> pm_stay_wake nesting (which I would argue against), we would need an
>> >> active count. It would also require a handle, which is a change Rafael
>> >> said would not fly.
>
> Never mind the handles for now. ?As for the nesting, we effectively
> don't have it when the pm_wakeup_event interface is used. ?The
> pm_stay_awake/pm_relax interface _is_ nested, but since that interface
> isn't used anywhere yet, we can't say whether it really should be
> nested or not. ?Maybe we'll find out in the end that it shouldn't be.
>
You cannot easily mix timeouts, cancellations and nesting.
Wakelocks/suspend blockers allow you to mix timeouts and
cancellations.
> Consider an input event queue as a typical case. ?You would call
> pm_stay_awake when an item is added to an empty queue, and you would
> call pm_relax when the last item is removed from a queue. ?The nesting
> count would never be > 1, so it wouldn't make any difference either
> way.
>
The cleanup is a little simpler when you don't nest and there is less
chance that a missed edge case prevents suspend forever (we had a few
of those bugs in our userspace code that used nested wakelocks). If
the above is all you do, then you block suspend forever if someone
closes an non-empty input device.
>> >> >> sleep_time, total time the wake lock has been active when the screen was off.
>> >> >
>> >> > Not applicable to general systems. ?Is there anything like it that
>> >> > _would_ apply in general?
>> >> >
>> >>
>> >> The screen off is how it is used on android, the stats is keyed of
>> >> what user space wrote to /sys/power/state. If "on" was written the
>> >> sleep time is not updated.
>
> I guess we could keep track of pm_stay_awake or pm_wakeup_event calls
> made between a read and write of /sys/power/wakeup_count (i.e., while
> events_check_enabled is set). ?Would that be roughly equivalent?
>
Roughly, yes. (or even just while blocking the read from
/sys/power/wakeup_count).
>> >> The merged user space interface makes this unclear to me. When I first
>> >> used suspend on android I had a power manager process that opened all
>> >> the input devices and reset a screen off timeout every time there was
>> >> an input event. If the input layer uses pm_stay_awake to block suspend
>> >> when the queue is not empty, this will deadlock with the current
>> >> interface since reading the wake count will block forever if an input
>> >> event occurred right after the power manager decides to suspend.
>> >
>> > No, in that case suspend will be aborted, IIUC.
>> >
>>
>> How? Your pm_get_wakeup_count function loops until events_in_progress becomes 0.
>
> The problem is that the same task is reading /sys/power/wakeup_count
> (thus waiting for an input event queue to drain) and also reading an
> input event queue. ?Clearly this will result in deadlock, but there
> must be a reasonably simple way around it. ?For example, carry out
> those two activities in separate threads.
>
Yes, but my point is that user-space code that is safe if the driver
does not block suspend until the queue is empty becomes unsafe if it
does. Also note that it is not enough to just use two separate threads
for this, the thread that reads /sys/power/wakeup_count cannot hold a
lock while reading, or directly provide the user space wakelock api.
I do think it is possible to use this api and provide a user space
wakelock api (by having a dedicated thread that suspends), but it is
more complicated than using the asynchronous wakelock/suspend blocker
api.
--
Arve Hj?nnev?g
2010/8/8 Rafael J. Wysocki <[email protected]>:
> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
...
>> The suspend blocking work api would have to change so the caller to passes
>> a device in, which I think would make that api less flexible. Mostly the
>> problem is that we need separate stats for wakelocks created by a
>> single driver. For instance we will still need a user-space interface
>> to block suspend on android devices (lower level services than the
>> power manager need to block suspend), with the stats in the device
>> struct we have to create a new device for every wakelock user space
>> creates in the kernel.
>
> Well, what about managing these stats in user space?
>
The java wakelocks have stats in user space, but the lower level
services that use the kernel api do not show up there.
>> There is also the issue of reading the stats. It is a lot easier to
>> read a single stats file, than looping though every device on the
>> system (when most of the devices never block suspend).
>
> It seems you can have a list of the "interesting" ones.
>
I'm not sure what you mean. If you mean add a procfs or debugfs api
that lists the stats for devices that have used the api, then yes that
should work. If I have a devices where the battery drained too
quickly, I run cat /proc/wakelocks which has all the reasons why it
was not suspended.
...
>> >> >> total_time, total time the wake lock has been active. This one should
>> >> >> be obvious.
>> >> >
>> >> > Also easily added.
>> >> >
>> >> Only with a handle passed to all the calls.
>> >
>> > Well, I'm kind of tired of this "my solution is the only acceptable one"
>> > mindset. ?IMHO, it's totally counter productive.
>> >
>>
>> How do you propose to track how long a driver has blocked suspend when
>> you have an unblock call that takes no arguments.
>
> You can extend pm_relax() to take a dev argument and measure the time between
> pm_stay_awake() and pm_relax() called for the same device.
>
As long as it is not optional.
>> >> >> sleep_time, total time the wake lock has been active when the screen was off.
>> >> >
>> >> > Not applicable to general systems. ?Is there anything like it that
>> >> > _would_ apply in general?
>> >> >
>> >>
>> >> The screen off is how it is used on android, the stats is keyed of
>> >> what user space wrote to /sys/power/state. If "on" was written the
>> >> sleep time is not updated.
>> >>
>> >> >> max_time, longest time the wakelock was active uninterrupted. This
>> >> >> used less often, but the battery on a device was draining fast, but
>> >> >> the problem went away before looking at the stats this will show if a
>> >> >> wakelock was active for a long time.
>> >> >
>> >> > Again, easily added. ?The only drawback is that all these additions
>> >> > will bloat the size of struct device. ?Of course, that's why you used
>> >> > separately-allocated structures for your wakelocks. ?Maybe we can
>> >> > change to do the same; it seems likely that the majority of device
>> >> > structures won't ever be used for wakeup events.
>> >> >
>> >>
>> >> Since many wakelocks are not associated with s struct device we need a
>> >> separate object for this anyway.
>> >>
>> >> >> >> and I would prefer that the kernel interfaces would
>> >> >> >> encourage drivers to block suspend until user space has consumed the
>> >> >> >> event, which works for the android user space, instead of just long
>> >> >> >> enough to work with a hypothetical user space power manager.
>> >> >
>> >> > Rafael doesn't _discourage_ drivers from doing this. ?However you have
>> >> > to keep in mind that many kernel developers are accustomed to working
>> >> > on systems (mostly PCs) with a different range of hardware devices from
>> >> > embedded systems like your phones. ?With PCI devices(*), for example,
>> >> > there's no clear point where a wakeup event gets handed off to
>> >> > userspace.
>> >> >
>> >> > On the other hand, there's no reason the input layer shouldn't use
>> >> > pm_stay_awake and pm_relax. ?It simply hasn't been implemented yet.
>> >> ...
>> >>
>> >> The merged user space interface makes this unclear to me. When I first
>> >> used suspend on android I had a power manager process that opened all
>> >> the input devices and reset a screen off timeout every time there was
>> >> an input event. If the input layer uses pm_stay_awake to block suspend
>> >> when the queue is not empty, this will deadlock with the current
>> >> interface since reading the wake count will block forever if an input
>> >> event occurred right after the power manager decides to suspend.
>> >
>> > No, in that case suspend will be aborted, IIUC.
>> >
>>
>> How? Your pm_get_wakeup_count function loops until events_in_progress becomes 0.
>
> So, to deadlock with it you'd have to call pm_stay_awake() and wait for it to
> complete. ?However, right now there are no means by which user space can call
> pm_stay_awake(), so this can't happen.
>
No that is not how it deadlocks. The input driver calls pm_stay_awake
which blocks the thread that reads from /sys/power/wakeup_count. If
that threads needs to run before the user-space reads from the input
device (either because it is the same thread, or because it provides a
user-space wakelock api) you have a deadlock.
> Of course, if you add pm_stay_awake() to an ioctl() code path, you should make
> sure that whoever uses that ioctl() won't be waiting for the power manager to
> read from /sys/power/wakeup_count. ?I guess your point is that this isn't
> possible to achieve?
>
My main point is that blocking suspend while the input event queue is
not empty changes what else is safe for the user-space process reading
/sys/power/wakeup_count.
--
Arve Hj?nnev?g
2010/8/8 Rafael J. Wysocki <[email protected]>:
> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>> 2010/8/7 Arve Hj?nnev?g <[email protected]>:
>> > 2010/8/7 Rafael J. Wysocki <[email protected]>:
>> >> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>> >>> 2010/8/6 Alan Stern <[email protected]>:
>> >>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
>> ...
>> >>> >> total_time, total time the wake lock has been active. This one should
>> >>> >> be obvious.
>> >>> >
>> >>> > Also easily added.
>> >>> >
>> >>> Only with a handle passed to all the calls.
>> >>
>> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
>> >> mindset. ?IMHO, it's totally counter productive.
>> >>
>> >
>> > How do you propose to track how long a driver has blocked suspend when
>> > you have an unblock call that takes no arguments.
>> >
>>
>> Also, I did not not see a response to my question about why you don't
>> want to pass a handle.
>
> It doesn't really matter what I personally want. ?In fact, I'm not totally
> opposed to that idea, although there are disadvantages (eg. a "handle"
> would really mean a pointer to an object with certain life cycle that needs to
> be managed by the caller and it's not that clear to me who should manage the
> objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
Wouldn't a single global handle work for the way you are handling pci
wakeup events? It looked like you just reset a global timeout every
time a pci wakeup event occurs.
> example). ?I sent a pull request for your original patchset to Linus after all. :-)
>
> I said I didn't think "it would fly", meaning that I was afraid the other kernel
> developers wouldn't like that change.
>
> The reason why I think so is that you'd like to add a whole new infrastructure
> whose only purpose would be debugging that would only be useful to systems
> using opportunistic suspend. ?That, however, is only Android right now and it
> cannot use the mainline kernel for other reasons, so basically we would add
> infrastructure that's useful to no one.
>
I'm not sure what you mean by this. The debugging is useful for anyone
using the api, not just Android, and a handle is also needed to mix
timeouts and pm_relax. The handle can be the device, but some drivers
need several handles per device.
--
Arve Hj?nnev?g
Hi!
> >I should have asked this earlier... What exactly are the apps'
> >compatibility constraints? Source-level APIs? Byte-code class-library
> >invocations? C/C++ dynamic linking? C/C++ static linking (in other
> >words, syscall)?
>
> For Java/Dalvik apps, the wakelock API is pertty high level -- it
> talks to a service via RPC (Binder) that actually interacts with the
> kernel. Changing the basic kernel<->userspace interface (within
Strange. Arve claimed that open/close is too slow, and few
microseconds faster ioctl is needed, and now we learn it actually uses
RPC.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Aug 9, 2010 at 12:26 AM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> >I should have asked this earlier... What exactly are the apps'
>> >compatibility constraints? Source-level APIs? Byte-code class-library
>> >invocations? C/C++ dynamic linking? C/C++ static linking (in other
>> >words, syscall)?
>>
>> For Java/Dalvik apps, the wakelock API is pertty high level -- it
>> talks to a service via RPC (Binder) that actually interacts with the
>> kernel. Changing the basic kernel<->userspace interface (within
>
> Strange. Arve claimed that open/close is too slow, and few
> microseconds faster ioctl is needed, and now we learn it actually uses
> RPC.
For the high level Java API, yes. For lower level userspace code,
like the code that processes keypresses, the kernel interface is used
directly. I think an open/close per keypress would be a bit
excessive, for example. In any case, that ignores the fact that it's
useful to have statistics, which are tricky to maintain meaningfully
if you destroy the handle after use every time (by closing the fd).
Brian
> I have to worry about manually killing off applications when memory
> gets low, I actually thought it was incredibly sucky. It was a
> miniature, badly done laptop.
Likewise I thought the lack of proper multi-tasking apps in Android was
comically bad. Nice device completely wrecked by the inability to flip
between running apps each with their own screen - something that was old
tech in 1990.
It's no use looking at this from an "In my opinion" angle. A proper
solution works for most if not all opinions except maybe around corner
cases.
> * allowing arbitrary applications that users can interact with
> simultaneously (which implies a window manager, the need to have
> the concept of window focus for keyboard input), etc?
That's also untrue as anyone who has worked in industrial control or
entertainment systems will tell you. You may well have fourteen apps
driving fourteen display/input devices and no window manager.
> would agree that in the ideal world, it would be nice if you could
> have applications that make the correct performance/battery
> utilization tradeoff for devices running on 800 mWh batteries, 94,000
> mWh batteries, and while running on the AC mains. But I don't believe
> that it's likely to be true, and if you want to try to beat up on
> application writers one at a time to be power optimized --- as far as
> I'm concerned, that's an argument *for* suspend blockers, since I'm
> not big believer in plans that begin, "First, you command the tides of
> the sea to go back", King Canute style. :-)
Suspend blockers drive the system policy part way into the apps, that in
turn makes the apps very vulnerable to change in their environment because
you've specialised them. I am sure that in the Android world it's
considered fine, and that the marketing and business people even like
this binding together - but it doesn't generalise and will blow up in
people's faces in the future.
To consider your tide analogy - suspend blockers is like trying to
program the waves individually. Show me a suspend blocker aware open
office patch 8)
On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
[ . . . ]
> > would agree that in the ideal world, it would be nice if you could
> > have applications that make the correct performance/battery
> > utilization tradeoff for devices running on 800 mWh batteries, 94,000
> > mWh batteries, and while running on the AC mains. But I don't believe
> > that it's likely to be true, and if you want to try to beat up on
> > application writers one at a time to be power optimized --- as far as
> > I'm concerned, that's an argument *for* suspend blockers, since I'm
> > not big believer in plans that begin, "First, you command the tides of
> > the sea to go back", King Canute style. :-)
>
> Suspend blockers drive the system policy part way into the apps, that in
> turn makes the apps very vulnerable to change in their environment because
> you've specialised them. I am sure that in the Android world it's
> considered fine, and that the marketing and business people even like
> this binding together - but it doesn't generalise and will blow up in
> people's faces in the future.
>
> To consider your tide analogy - suspend blockers is like trying to
> program the waves individually. Show me a suspend blocker aware open
> office patch 8)
But wouldn't an office suite run as a power-oblivious application on an
Android device? After all, office applications do not need to run when
the screen is turned off, so these the applications do not need to use
suspend blockers. That said, I could easily imagine that significant
work would be required to make OpenOffice run on Android, not due to
suspend blockers, but rather due to Android's unusual user space.
On devices that do not have suspend blockers, a normal application runs
in a manner similar to a hypothetical Android application that acquires
a suspend blocker when it starts and holds that suspend blocker until
it exits. In contrast with Android, this situation requires that each
and every application be carefully written to avoid battery drain,
which I suspect is what Ted is getting at with his King Canute analogy.
Thanx, Paul
On Mon, 9 Aug 2010, Paul E. McKenney wrote:
> On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
>
> [ . . . ]
>
>>> would agree that in the ideal world, it would be nice if you could
>>> have applications that make the correct performance/battery
>>> utilization tradeoff for devices running on 800 mWh batteries, 94,000
>>> mWh batteries, and while running on the AC mains. But I don't believe
>>> that it's likely to be true, and if you want to try to beat up on
>>> application writers one at a time to be power optimized --- as far as
>>> I'm concerned, that's an argument *for* suspend blockers, since I'm
>>> not big believer in plans that begin, "First, you command the tides of
>>> the sea to go back", King Canute style. :-)
>>
>> Suspend blockers drive the system policy part way into the apps, that in
>> turn makes the apps very vulnerable to change in their environment because
>> you've specialised them. I am sure that in the Android world it's
>> considered fine, and that the marketing and business people even like
>> this binding together - but it doesn't generalise and will blow up in
>> people's faces in the future.
>>
>> To consider your tide analogy - suspend blockers is like trying to
>> program the waves individually. Show me a suspend blocker aware open
>> office patch 8)
>
> But wouldn't an office suite run as a power-oblivious application on an
> Android device? After all, office applications do not need to run when
> the screen is turned off, so these the applications do not need to use
> suspend blockers. That said, I could easily imagine that significant
> work would be required to make OpenOffice run on Android, not due to
> suspend blockers, but rather due to Android's unusual user space.
pick your application if you don't like the example.
but also, which android system should the applicaton be written for? the
phone with a 800maH battery or a larger device with a 94,000maH battery?
well bahaved applications (not doing unnecessary wakeups, etc) are well
bahaved, no matter what system they are on (explicitly setting allowable
timer fuzz is linux specific, but will again help on any system)
David Lang
> But wouldn't an office suite run as a power-oblivious application on an
> Android device? After all, office applications do not need to run when
I was waiting for soemone to leap down the pit I dug Office suites have
some quite important background activities. Consider the case of a power
oblivious Open Office. You type a critical document, you suspend, your
phone battery dies a bit later, you lost your document. Office suites do
timed backing up as one simple obvious example. That could become a power
aware behaviour but the truely power oblivious office suite is a myth.
> the screen is turned off, so these the applications do not need to use
> suspend blockers. That said, I could easily imagine that significant
> work would be required to make OpenOffice run on Android, not due to
> suspend blockers, but rather due to Android's unusual user space.
You are tightly linking suspend blockers with Android. If they were a
sensible general solution they would be generic not tied closely to
Android
Some of the other bad assumptions being made in this discussion:
- That the phone is special. Todays Android phones are up with the PC's
of some years back (but with better graphics and more faster storage),
in a few more generations of the technology what will they look like ?
I'm sure that within a few years there will be people playing Warcraft
or similar on their phone in the train.
- That Android will continue to tbe offering the same services in future
as today. If it does it'll go the way of PalmOS and Symbian. Equally
you can't just bust all the apps as it changes
As devices get more complex and varied you cannot afford to put the
detailed awareness of platform behaviour in the applications. It
doesn't scale. Android developers are haivng enough fun coping with all
the OS variants, customisations and new phones - and thats far less
variety than PC hardware. Generally the PC app folks are not having the
same level of problem - so ask why ?
> On devices that do not have suspend blockers, a normal application runs
> in a manner similar to a hypothetical Android application that acquires
> a suspend blocker when it starts and holds that suspend blocker until
> it exits. In contrast with Android, this situation requires that each
> and every application be carefully written to avoid battery drain,
> which I suspect is what Ted is getting at with his King Canute analogy.
Which is flawed and not the case. The same argument could be made for
multi-tasking
DOS "Each application implements its own internal
multitasking/polling if needed"
Windows 3.x "Each application has an event loop and is built
in a certain way" (the 'suspend blocker' mentality)
Real OS "The scheduler operates in a manner which prevents
CPU hogs breaking the system or abusing it sufficiently to threaten its
functionality"
The same applies to power. Only the OS has the big picture and can hide
the hardware and general policy variety from the application.
OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
runs on virtual machines, it runs in power sensitive environments, it
runs in thermally constrained environments, it runs in I/O constrained
environments, it runs in latency constrained environments etc etc
All the same code, true some work has been done to make it behave
politely but the rest is down to the OS doing its job - deploying the
resources available while considering and obeying the constraints
present, in a manner which makes best use of the resources to achieve the
policy goals of the system.
And not unsurprisingly that all starts to look like Stafford Beer's good
old viable systems model.
Alan
On Mon, Aug 09, 2010 at 11:28:02AM -0700, [email protected] wrote:
> On Mon, 9 Aug 2010, Paul E. McKenney wrote:
>
> >On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
> >
> >[ . . . ]
> >
> >>>would agree that in the ideal world, it would be nice if you could
> >>>have applications that make the correct performance/battery
> >>>utilization tradeoff for devices running on 800 mWh batteries, 94,000
> >>>mWh batteries, and while running on the AC mains. But I don't believe
> >>>that it's likely to be true, and if you want to try to beat up on
> >>>application writers one at a time to be power optimized --- as far as
> >>>I'm concerned, that's an argument *for* suspend blockers, since I'm
> >>>not big believer in plans that begin, "First, you command the tides of
> >>>the sea to go back", King Canute style. :-)
> >>
> >>Suspend blockers drive the system policy part way into the apps, that in
> >>turn makes the apps very vulnerable to change in their environment because
> >>you've specialised them. I am sure that in the Android world it's
> >>considered fine, and that the marketing and business people even like
> >>this binding together - but it doesn't generalise and will blow up in
> >>people's faces in the future.
> >>
> >>To consider your tide analogy - suspend blockers is like trying to
> >>program the waves individually. Show me a suspend blocker aware open
> >>office patch 8)
> >
> >But wouldn't an office suite run as a power-oblivious application on an
> >Android device? After all, office applications do not need to run when
> >the screen is turned off, so these the applications do not need to use
> >suspend blockers. That said, I could easily imagine that significant
> >work would be required to make OpenOffice run on Android, not due to
> >suspend blockers, but rather due to Android's unusual user space.
>
> pick your application if you don't like the example.
I like the office-suite example just fine.
> but also, which android system should the applicaton be written for?
> the phone with a 800maH battery or a larger device with a 94,000maH
> battery?
Does battery size make a difference in this particular case?
> well bahaved applications (not doing unnecessary wakeups, etc) are
> well bahaved, no matter what system they are on
Yep. Your point being what exactly? That all applications should be
required to be power-optimized, and that any technology that automates
energy efficiency should be rejected out of hand? If so, please justify
your position.
> (explicitly setting
> allowable timer fuzz is linux specific, but will again help on any
> system)
Setting aside the question of how timer fuzz will help on non-Linux
systems if timer fuzz is specific to Linux...
Thanx, Paul
On Mon, Aug 9, 2010 at 12:18 PM, Alan Cox <[email protected]> wrote:
>> But wouldn't an office suite run as a power-oblivious application on an
>> Android device? After all, office applications do not need to run when
>
> I was waiting for soemone to leap down the pit I dug Office suites have
> some quite important background activities. Consider the case of a power
> oblivious Open Office. You type a critical document, you suspend, your
> phone battery dies a bit later, you lost your document. Office suites do
> timed backing up as one simple obvious example. That could become a power
> aware behaviour but the truely power oblivious office suite is a myth.
>
>> the screen is turned off, so these the applications do not need to use
>> suspend blockers. That said, I could easily imagine that significant
>> work would be required to make OpenOffice run on Android, not due to
>> suspend blockers, but rather due to Android's unusual user space.
>
> You are tightly linking suspend blockers with Android. If they were a
> sensible general solution they would be generic not tied closely to
> Android
Doesn't the same problem exist on my linux laptop? I write out my
manifesto in open office, close the lid of my laptop, the system
suspends before my huge document finishes writing out, later my
battery dies or I foolishly remove it or whatnot... the main
difference seems to be that laptops, with their big 'ol batteries, are
less aggressive about power management and the result is wider windows
before and less frequent wakeups from suspend and thus better odds at
missing the race condition.
As Arve has pointed out previously, there are a number of uses for
suspend blockers, even on plugged-into-the-wall systems -- take his
example of wanting his mythtv backend to power down when not busy, but
never power down when he happens to be using it on console, or issues
with multiple services that want to wake up and keep the device awake
while working.
Brian
On Mon, 9 Aug 2010, Alan Cox wrote:
>> But wouldn't an office suite run as a power-oblivious application on an
>> Android device? After all, office applications do not need to run when
>
> I was waiting for soemone to leap down the pit I dug Office suites have
> some quite important background activities. Consider the case of a power
> oblivious Open Office. You type a critical document, you suspend, your
> phone battery dies a bit later, you lost your document. Office suites do
> timed backing up as one simple obvious example. That could become a power
> aware behaviour but the truely power oblivious office suite is a myth.
this is a good example of why the office suite should be a privilaged
application. If the system were to consider it privilaged, it could
wake up when the timer is scheduled to fire to save the document.
the office suite probably has a periodic timer that would fire every 10
min no matter what, but if there was a reason to change it, it could be
modified to only setup the timer when the document is changed. If no
changes can take place because the system is asleep, the timer never gets
setup.
David Lang
On Monday, August 09, 2010, Arve Hj?nnev?g wrote:
> 2010/8/8 Rafael J. Wysocki <[email protected]>:
> > On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> >> 2010/8/7 Arve Hj?nnev?g <[email protected]>:
> >> > 2010/8/7 Rafael J. Wysocki <[email protected]>:
> >> >> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
> >> >>> 2010/8/6 Alan Stern <[email protected]>:
> >> >>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
> >> ...
> >> >>> >> total_time, total time the wake lock has been active. This one should
> >> >>> >> be obvious.
> >> >>> >
> >> >>> > Also easily added.
> >> >>> >
> >> >>> Only with a handle passed to all the calls.
> >> >>
> >> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
> >> >> mindset. IMHO, it's totally counter productive.
> >> >>
> >> >
> >> > How do you propose to track how long a driver has blocked suspend when
> >> > you have an unblock call that takes no arguments.
> >> >
> >>
> >> Also, I did not not see a response to my question about why you don't
> >> want to pass a handle.
> >
> > It doesn't really matter what I personally want. In fact, I'm not totally
> > opposed to that idea, although there are disadvantages (eg. a "handle"
> > would really mean a pointer to an object with certain life cycle that needs to
> > be managed by the caller and it's not that clear to me who should manage the
> > objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
>
> Wouldn't a single global handle work for the way you are handling pci
> wakeup events?
Not really, because I'd like to know the number of wakeups associated with
the given device.
> It looked like you just reset a global timeout every time a pci wakeup event
> occurs.
We bump up the per-device counter of wakeup events in addition to that.
> > example). I sent a pull request for your original patchset to Linus after all. :-)
> >
> > I said I didn't think "it would fly", meaning that I was afraid the other kernel
> > developers wouldn't like that change.
> >
> > The reason why I think so is that you'd like to add a whole new infrastructure
> > whose only purpose would be debugging that would only be useful to systems
> > using opportunistic suspend. That, however, is only Android right now and it
> > cannot use the mainline kernel for other reasons, so basically we would add
> > infrastructure that's useful to no one.
> >
>
> I'm not sure what you mean by this. The debugging is useful for anyone
> using the api, not just Android, and a handle is also needed to mix
> timeouts and pm_relax.
The purpose of the debugging would be to be able to figure out why the system
is staying in the working state, which is only relevant for systems that use
opportunistic suspend.
If opportunistic suspend isn't used, it makes sense to ask which
device caused suspend (initiated by the user) to be aborted and for this
purpose it is sufficient to count wakeup events associated with each
device (you need to preserve the pre-suspend values of these counters, but
that can be done by a user space power manager just fine).
> The handle can be the device, but some drivers need several handles per
> device.
That depends on how precise the collected debug information should be and
that, in turn, depends on what it's going to be used for.
Anyway, as I said I'm not opposed to the idea of using a special type of
objects for collecting debug information on wakeup events, so please free to
submit patches modifying the current mainline kernel code in that direction.
Thanks,
Rafael
2010/8/9 Rafael J. Wysocki <[email protected]>:
> On Monday, August 09, 2010, Arve Hj?nnev?g wrote:
>> 2010/8/8 Rafael J. Wysocki <[email protected]>:
>> > On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>> >> 2010/8/7 Arve Hj?nnev?g <[email protected]>:
>> >> > 2010/8/7 Rafael J. Wysocki <[email protected]>:
>> >> >> On Saturday, August 07, 2010, Arve Hj?nnev?g wrote:
>> >> >>> 2010/8/6 Alan Stern <[email protected]>:
>> >> >>> > On Thu, 5 Aug 2010, Arve Hj?nnev?g wrote:
>> >> ...
>> >> >>> >> total_time, total time the wake lock has been active. This one should
>> >> >>> >> be obvious.
>> >> >>> >
>> >> >>> > Also easily added.
>> >> >>> >
>> >> >>> Only with a handle passed to all the calls.
>> >> >>
>> >> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
>> >> >> mindset. ?IMHO, it's totally counter productive.
>> >> >>
>> >> >
>> >> > How do you propose to track how long a driver has blocked suspend when
>> >> > you have an unblock call that takes no arguments.
>> >> >
>> >>
>> >> Also, I did not not see a response to my question about why you don't
>> >> want to pass a handle.
>> >
>> > It doesn't really matter what I personally want. ?In fact, I'm not totally
>> > opposed to that idea, although there are disadvantages (eg. a "handle"
>> > would really mean a pointer to an object with certain life cycle that needs to
>> > be managed by the caller and it's not that clear to me who should manage the
>> > objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
>>
>> Wouldn't a single global handle work for the way you are handling pci
>> wakeup events?
>
> Not really, because I'd like to know the number of wakeups associated with
> the given device.
>
For debugging purposes right? I'm not sure automatically counting
wakeup events from pm_stay_awake and pm_wakeup_event is the best way
to do this. To avoid race conditions these calls have to be made for
every event that could also be a wakeup event, which means the actual
wakeup event easily gets lost in the noise. This is why I had a
separate wakeup count that only increments on the fist call to
wake_lock after each suspend, but this did not work that well either.
>> It looked like you just reset a global timeout every time a pci wakeup event
>> occurs.
>
> We bump up the per-device counter of wakeup events in addition to that.
>
>> > example). ?I sent a pull request for your original patchset to Linus after all. :-)
>> >
>> > I said I didn't think "it would fly", meaning that I was afraid the other kernel
>> > developers wouldn't like that change.
>> >
>> > The reason why I think so is that you'd like to add a whole new infrastructure
>> > whose only purpose would be debugging that would only be useful to systems
>> > using opportunistic suspend. ?That, however, is only Android right now and it
>> > cannot use the mainline kernel for other reasons, so basically we would add
>> > infrastructure that's useful to no one.
>> >
>>
>> I'm not sure what you mean by this. The debugging is useful for anyone
>> using the api, not just Android, and a handle is also needed to mix
>> timeouts and pm_relax.
>
> The purpose of the debugging would be to be able to figure out why the system
> is staying in the working state, which is only relevant for systems that use
> opportunistic suspend.
>
Only if the drivers do not have bugs. A driver calling pm_say_awake
without a matching pm_relax call will prevent any race free suspend
from succeeding.
> If opportunistic suspend isn't used, it makes sense to ask which
> device caused suspend (initiated by the user) to be aborted and for this
> purpose it is sufficient to count wakeup events associated with each
> device (you need to preserve the pre-suspend values of these counters, but
> that can be done by a user space power manager just fine).
>
>> The handle can be the device, but some drivers need several handles per
>> device.
>
> That depends on how precise the collected debug information should be and
> that, in turn, depends on what it's going to be used for.
>
It is not just debug information. Drivers that mix wake_lock_timeout
and wake_unlock do not map to the current api.
> Anyway, as I said I'm not opposed to the idea of using a special type of
> objects for collecting debug information on wakeup events, so please free to
> submit patches modifying the current mainline kernel code in that direction.
>
How do you prefer to handle your pci wakeup events? Add a handle to
every device or pci device? Or use a global handle to avoid the race
and report wakeup events for debugging separately?
--
Arve Hj?nnev?g
On Mon, Aug 09, 2010 at 08:18:22PM +0100, Alan Cox wrote:
> > But wouldn't an office suite run as a power-oblivious application on an
> > Android device? After all, office applications do not need to run when
>
> I was waiting for soemone to leap down the pit I dug Office suites have
> some quite important background activities. Consider the case of a power
> oblivious Open Office. You type a critical document, you suspend, your
> phone battery dies a bit later, you lost your document. Office suites do
> timed backing up as one simple obvious example. That could become a power
> aware behaviour but the truely power oblivious office suite is a myth.
It is a sad day on LKML when we are busy digging pits for each other.
On the other hand, I have seen far sadder days, and the pit you dug
happens to lead somewhere useful. As Brian noted in his reply, the
situation you call out can occur with manual suspend-to-RAM already:
the fact is that this is a design choice. You could indeed make a
PM-driving office application if you wished, or run the same application
as a power-oblivious application. There is a slight difference in the
contract with the user. Of course, it is quite clear which one -you-
prefer, but preferences can vary.
> > the screen is turned off, so these the applications do not need to use
> > suspend blockers. That said, I could easily imagine that significant
> > work would be required to make OpenOffice run on Android, not due to
> > suspend blockers, but rather due to Android's unusual user space.
>
> You are tightly linking suspend blockers with Android. If they were a
> sensible general solution they would be generic not tied closely to
> Android
Android is certainly where suspend blockers originated, and is to the best
of my knowledge is still the only platform that uses them. But there is
a first user of every new mechanism, and for some time that first user
will by definition be the only user of that mechanism. So the fact
that Android is most probably the only user of suspend blockers does
not prove anything about whether or not suspend blockers are sensible.
> Some of the other bad assumptions being made in this discussion:
>
> - That the phone is special. Todays Android phones are up with the PC's
> of some years back (but with better graphics and more faster storage),
> in a few more generations of the technology what will they look like ?
> I'm sure that within a few years there will be people playing Warcraft
> or similar on their phone in the train.
Indeed, people have played games on their cellphones for some years.
Not sure whether any of the games resembles World of Warcraft, but they
probably soon will. If so, perhaps they will make use of significant
hardware acceleration -- most other embedded systems do so.
But that doesn't guarantee that solutions developed for PCs and laptops
will be optimal (or even usable) on cellphones. Sufficient difference
in scale can easily change the form of the optimal solution, so you
have not yet made your case. (For that matter, you also haven't proven
that adoption of suspend blockers or something like them depends on the
assumption that cellphones are special.)
> - That Android will continue to tbe offering the same services in future
> as today. If it does it'll go the way of PalmOS and Symbian. Equally
> you can't just bust all the apps as it changes
I hope that no one is arguing that Android will remain unchanged, just
as I hope no one would argue that Linux will remain unchanged. In fact,
I am quite confident that both Linux and Android will continue to change.
So exactly what point were you attempting to make here?
As to busting all apps, lthough there have been situations where busting
all the apps turned out to be the right thing to do, I agree that these
situations are extremely rare. Such situations are usually associated
with the emergence of a new high-volume platform.
> As devices get more complex and varied you cannot afford to put the
> detailed awareness of platform behaviour in the applications. It
> doesn't scale. Android developers are haivng enough fun coping with all
> the OS variants, customisations and new phones - and thats far less
> variety than PC hardware. Generally the PC app folks are not having the
> same level of problem - so ask why ?
>From what I can see, the Android developers are suffering less than
the PC developers were suffering when the PC was the same age that
Android is now. For that matter, suspend blockers don't put detailed
awareness of platform behavior into apps. You must look to the heavily
power-optimized apps to find that kind of awareness.
> > On devices that do not have suspend blockers, a normal application runs
> > in a manner similar to a hypothetical Android application that acquires
> > a suspend blocker when it starts and holds that suspend blocker until
> > it exits. In contrast with Android, this situation requires that each
> > and every application be carefully written to avoid battery drain,
> > which I suspect is what Ted is getting at with his King Canute analogy.
>
> Which is flawed and not the case.
Hmmm... Exactly which part do you consider flawed? Let's take it
one sentence at a time. The devices that I know of that lack suspend
blockers also lack opportunistic suspend. Therefore, all applications on
such devices run as would an application that acquired a suspend blocker
when it started and did not release that suspend blocker until it exited.
Pretty straightforward.
As for the first part of the second sentence, you yourself have argued
that each and every application should be carefully written to avoid
battery drain (or, equivalently, to promote energy efficiency), so
presumably the flaw does not reside there. That leaves the second
half of that sentence, for which we both must defer to Ted. But Ted's
intended meaning of his King Canute analogy does not affect the argument
as to whether or not suspend blockers (or, again, something like them)
are useful.
> The same argument could be made for
> multi-tasking
>
> DOS "Each application implements its own internal
> multitasking/polling if needed"
>
> Windows 3.x "Each application has an event loop and is built
> in a certain way" (the 'suspend blocker' mentality)
>
> Real OS "The scheduler operates in a manner which prevents
> CPU hogs breaking the system or abusing it sufficiently to threaten its
> functionality"
I really do like this progression. I will return to it further down.
> The same applies to power. Only the OS has the big picture and can hide
> the hardware and general policy variety from the application.
The OS can be said to possess the full picture only if the applications
communicate their portion of the picture to the OS. Linux has quite a
few APIs devoted to this sort of communication, many of them mandated
by POSIX. Some people are proposing suspend blockers (or something like
them) as another member of this set of APIs.
> OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
> runs on virtual machines, it runs in power sensitive environments, it
> runs in thermally constrained environments, it runs in I/O constrained
> environments, it runs in latency constrained environments etc etc
And there are numerous environments in which it will not run. So what?
> All the same code, true some work has been done to make it behave
> politely but the rest is down to the OS doing its job - deploying the
> resources available while considering and obeying the constraints
> present, in a manner which makes best use of the resources to achieve the
> policy goals of the system.
And if the work has not been done on the application, and if there is
nothing like suspend blockers, the OS cannot do its job. So how exactly
does this support your position?
Which brings us to the progression from DOS to Windows 3.x to Real
OS. Why can the Real OS's scheduler can operate "in a manner which
prevents CPU hogs from breaking the system or abusing it sufficiently
to threaten its functionality" while still allowing applications with
special requirements to operate correctly? One reason is the advent
of any number of APIs that communicate special properties of specific
applications to the OS, including the old nice() system call, POSIX
realtime, numerous facilities to communicate application properties to
the VM system, and so on.
Given this context, are you sure that suspend blockers are not the next
step in the Real OS progression? Or some QoS mechanism that subsumes
suspend blockers? However, there is a lot of negative experience
around general-purpose QoS mechanisms -- you have to be quite careful
in order to avoid spending more energy computing QoS than you would
otherwise spend on the application's computations. The usual way out of
this trap is to abandon generality in favor of exploiting the commonly
occurring special cases. For all I know, raw suspend blockers might be
the appropriate special case.
> And not unsurprisingly that all starts to look like Stafford Beer's good
> old viable systems model.
Hmmm... I do like "Absolutum Obsoletum", especially if it really does
translate to "If it works it's out of date." However, I am not at all
convinced that it supports your position! ;-)
Thanx, Paul
> situation you call out can occur with manual suspend-to-RAM already:
> the fact is that this is a design choice. You could indeed make a
Losing data is a design choice ? The application set a timer, the OS
shouldn't be ignoring it in that situation. It might want to delay it, it
might want to warn the user its hogging things it shouldnt (powertop,
battery usage monitors in Android etc)
> will by definition be the only user of that mechanism. So the fact
> that Android is most probably the only user of suspend blockers does
> not prove anything about whether or not suspend blockers are sensible.
They don't appear to solve the constraints on power management that you
have in other environments, nor do they happen to be conveniently
backward compatible or available on other platforms - which makes code
hard to port.
> But that doesn't guarantee that solutions developed for PCs and laptops
> will be optimal (or even usable) on cellphones. Sufficient difference
Your cellphone is to all intents a laptop from ten years ago, it even has
a similar display resolution and internet availability. The underlying
difference between the two is solely form factor - the laptop had a
better keyboard.
> I hope that no one is arguing that Android will remain unchanged, just
> as I hope no one would argue that Linux will remain unchanged. In fact,
> I am quite confident that both Linux and Android will continue to change.
> So exactly what point were you attempting to make here?
That anything which ties to a particular style of behaviour and set of
current usage assumptions is broken. If you rewrite all the apps to
Android 2.1 and design in a single tasking model then you'll have to
unrewrite half of it again when Android grows up. Ditto suspend blockers
- encode too much policy in your apps and you lose the ability to change
the environment under them. See the mess Microsoft got into with Win16 on
Win32. Compare with Linux 32bit on Linux 64bit.
> As to busting all apps, lthough there have been situations where busting
> all the apps turned out to be the right thing to do, I agree that these
> situations are extremely rare. Such situations are usually associated
> with the emergence of a new high-volume platform.
Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely
right. It's merely that in certain cases the value in the market is large
enough that it can be used as a big stick to beat people into doing lots
of usually wasted work.
> Hmmm... Exactly which part do you consider flawed? Let's take it
> one sentence at a time. The devices that I know of that lack suspend
> blockers also lack opportunistic suspend. Therefore, all applications on
> such devices run as would an application that acquired a suspend blocker
> when it started and did not release that suspend blocker until it exited.
> Pretty straightforward.
What do you mean by "opportunistic suspend", lots of systems drop into
lowest power states whenever they can. "Suspend is different" is a bit of
Android religion that I am dubious has any basis in reality as seen from
the application end of the universe.
You may also wish to review the earlier parts of the discussion where it
was explicitly stated by several developers that they were using
"suspend" type modes as power states already and not using suspend
blockers. So it's being done, today on ARM and your statement is directly
contradicting the code. Modern ARM processors and x86 MID devices can
suspend and resume extremely fast (fast enough that the fact Linux x86
rewriting all the SMP alternatives on suspend/resume is a measurable
problem). If this same property doesn't end up on big PC boxes in time
then I'd be very surprised. At that point the openoffice with suspend
blockers or oracle with suspend blockers question becomes rather relevant.
> As for the first part of the second sentence, you yourself have argued
> that each and every application should be carefully written to avoid
> battery drain (or, equivalently, to promote energy efficiency), so
No. I've argued that applications need to be generally well behaved, not
keep waking up, not burn cpu - which is a generic property applicable on
all environments not a specialisation.
> > OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
> > runs on virtual machines, it runs in power sensitive environments, it
> > runs in thermally constrained environments, it runs in I/O constrained
> > environments, it runs in latency constrained environments etc etc
>
> And there are numerous environments in which it will not run. So what?
It's one codebase for all of them and furthermore almost all of that was
done by modifying only the OS. Linux learned to do power throttling
without the app being involved, it learned to do virtualisation without
the app being changed, it is learning (with -rt) to handle to do real
time this way.
> > All the same code, true some work has been done to make it behave
> > politely but the rest is down to the OS doing its job - deploying the
> > resources available while considering and obeying the constraints
> > present, in a manner which makes best use of the resources to achieve the
> > policy goals of the system.
>
> And if the work has not been done on the application, and if there is
> nothing like suspend blockers, the OS cannot do its job.
I don't see any evidence to support that claim. I see evidence that there
are cases where apps wish to communicate their intentions around power
more clearly but a suspend blocker is a crude single case hammer. Today
most applications communicate their sleep/wake requirements fairly well by
sleeping, by executing code and by setting timers/alarms.
> Given this context, are you sure that suspend blockers are not the next
> step in the Real OS progression? Or some QoS mechanism that subsumes
> suspend blockers? However, there is a lot of negative experience
> around general-purpose QoS mechanisms -- you have to be quite careful
> in order to avoid spending more energy computing QoS than you would
> otherwise spend on the application's computations. The usual way out of
> this trap is to abandon generality in favor of exploiting the commonly
> occurring special cases. For all I know, raw suspend blockers might be
> the appropriate special case.
For Android possibly and I've never had any objection to Android keeping
suspend blockers in private patches. The claim is only a small number are
needed in their kernel so its a tiddly patch and the patch context will
no doubt keep it applying between releases and easy for them to maintain.
For the rest of us - I see no evidence it's generally useful. A QoS API
does appear to be generally useful but as you say you need to get the
performance right. However you can also tackle that the way we tackle
several other examples of one interface/many needs - such as schedulers,
security models and the like.
One interface to applications and one interface to drivers so that its
easy to maintain and you don't end up with hooks all over the place for
different things, then if it proves neccessary different implementations.
So yes maybe Android would use a "qos_basic" which returns -EOPNOTSUPP to
anything but a suspend blocker behaviour. The important thing about that
is that my device drivers, my applications and my other platforms don't
have to care that Android made this choice - they can still be generic
code.
That is why I used the Win16 example. The Win16 model encapsulated an
implementation into the API. Had they followed a more conventional
interface based around yielding then like MacOS they'd have had a far
smoother move to pre-emptive MT.
Alan
On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> > situation you call out can occur with manual suspend-to-RAM already:
> > the fact is that this is a design choice. You could indeed make a
>
> Losing data is a design choice ? The application set a timer, the OS
> shouldn't be ignoring it in that situation. It might want to delay it, it
> might want to warn the user its hogging things it shouldnt (powertop,
> battery usage monitors in Android etc)
So we should remove explicit system suspend from the kernel?
> > Hmmm... Exactly which part do you consider flawed? Let's take it
> > one sentence at a time. The devices that I know of that lack suspend
> > blockers also lack opportunistic suspend. Therefore, all applications on
> > such devices run as would an application that acquired a suspend blocker
> > when it started and did not release that suspend blocker until it exited.
> > Pretty straightforward.
>
> What do you mean by "opportunistic suspend", lots of systems drop into
> lowest power states whenever they can. "Suspend is different" is a bit of
> Android religion that I am dubious has any basis in reality as seen from
> the application end of the universe.
>
> You may also wish to review the earlier parts of the discussion where it
> was explicitly stated by several developers that they were using
> "suspend" type modes as power states already and not using suspend
> blockers. So it's being done, today on ARM and your statement is directly
> contradicting the code. Modern ARM processors and x86 MID devices can
> suspend and resume extremely fast (fast enough that the fact Linux x86
> rewriting all the SMP alternatives on suspend/resume is a measurable
> problem). If this same property doesn't end up on big PC boxes in time
> then I'd be very surprised. At that point the openoffice with suspend
> blockers or oracle with suspend blockers question becomes rather relevant.
There's a clear and absolute difference between system suspend and
entering the same hardware state from the idle loop. That difference is
that processes aren't scheduled until an explicit wakeup event occurs.
Android is entirely capable of entering the same low power state at idle
(it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but
if you have more than 0 scheduling wakeups a second then your power draw
is going to be greater.
I agree that we should be targetting 0 wakeups per second. I don't agree
that it's realistic to insist that a use model that assumes imperfect
software is an invalid use model.
--
Matthew Garrett | [email protected]
On Mon, Aug 09, 2010 at 11:24:53AM +0100, Alan Cox wrote:
> > I have to worry about manually killing off applications when memory
> > gets low, I actually thought it was incredibly sucky. It was a
> > miniature, badly done laptop.
> Likewise I thought the lack of proper multi-tasking apps in Android was
> comically bad. Nice device completely wrecked by the inability to flip
> between running apps each with their own screen - something that was old
> tech in 1990.
Rather beside the point for this thread and it's perhaps not so
intuitive as it ought to be but holding down the home button should do
what you're looking for here.
> > Losing data is a design choice ? The application set a timer, the OS
> > shouldn't be ignoring it in that situation. It might want to delay it, it
> > might want to warn the user its hogging things it shouldnt (powertop,
> > battery usage monitors in Android etc)
>
> So we should remove explicit system suspend from the kernel?
Explicit suspend is user triggered - in the laptop case its a bit
different. I don't btw like the fact that a laptop explicit suspend
doesn't end up as a dbus "save data" and openoffice save (or it didn't
last time I looked which is a while ago).
> There's a clear and absolute difference between system suspend and
> entering the same hardware state from the idle loop. That difference is
> that processes aren't scheduled until an explicit wakeup event occurs.
> Android is entirely capable of entering the same low power state at idle
> (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but
> if you have more than 0 scheduling wakeups a second then your power draw
> is going to be greater.
And nothing stops you also implementing a 'forced' suspend, although you
can do that nicely by simply stopping the process group that contains the
stuff you don't want to stop suspend and dropping into suspend when you
idle.
> I agree that we should be targetting 0 wakeups per second. I don't agree
> that it's realistic to insist that a use model that assumes imperfect
> software is an invalid use model.
No argument.
The question is what applications should be expressing to the kernel
which is not tied to assumptions like 'suspend mode' and which is generic.
We don't have xfs stuff for example splattered all over userspace and in
lots of drivers - we have generic interfaces. That way user community A
doesn't have to care about user community B's choices, and JFFS flash fs
people don't offend big data centre people and vice versa.
Alan
Which reminds me. I forgot a very important way that user space signals
the kernel as to its intents.
The kernel can see whether code is sleeping by choice or sleeping because
someone blocked it (eg a page fault). The kernel also knows a lot about
the event being waited for (much more so in -rt than base).
We don't capture all of that info but it seems it would advance progress
in the right direction to do so better.
Alan
On Tue, Aug 10, 2010 at 03:40:26PM +0100, Alan Cox wrote:
> > > Losing data is a design choice ? The application set a timer, the OS
> > > shouldn't be ignoring it in that situation. It might want to delay it, it
> > > might want to warn the user its hogging things it shouldnt (powertop,
> > > battery usage monitors in Android etc)
> >
> > So we should remove explicit system suspend from the kernel?
>
> Explicit suspend is user triggered - in the laptop case its a bit
> different. I don't btw like the fact that a laptop explicit suspend
> doesn't end up as a dbus "save data" and openoffice save (or it didn't
> last time I looked which is a while ago).
It's not inherently user triggered. Machines typically have an idle
timeout that triggers suspend. This differs from the Android
opportunistic suspend approach only in that the timeout is significantly
larger, primarily due to the greater latency involved.
> > There's a clear and absolute difference between system suspend and
> > entering the same hardware state from the idle loop. That difference is
> > that processes aren't scheduled until an explicit wakeup event occurs.
> > Android is entirely capable of entering the same low power state at idle
> > (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but
> > if you have more than 0 scheduling wakeups a second then your power draw
> > is going to be greater.
>
> And nothing stops you also implementing a 'forced' suspend, although you
> can do that nicely by simply stopping the process group that contains the
> stuff you don't want to stop suspend and dropping into suspend when you
> idle.
We've already had the discussion about this resulting in potential
deadlocks if there's any intercommunication between the trusted and
untrusted apps, and if untrusted apps can be the consumers of wakeup
events then you still end up with the wake event race condition. If we
want to avoid the case where system suspend can cause wakeup events to
be lost, we're pretty much required to implement something like suspend
blocks (and, in fact, Rafael's implementation of this is already
mainline).
> > I agree that we should be targetting 0 wakeups per second. I don't agree
> > that it's realistic to insist that a use model that assumes imperfect
> > software is an invalid use model.
>
> No argument.
>
> The question is what applications should be expressing to the kernel
> which is not tied to assumptions like 'suspend mode' and which is generic.
>
> We don't have xfs stuff for example splattered all over userspace and in
> lots of drivers - we have generic interfaces. That way user community A
> doesn't have to care about user community B's choices, and JFFS flash fs
> people don't offend big data centre people and vice versa.
I wholeheartedly agree. But nobody has yet provided a generic approach
to avoiding the loss of wakeup events, and that's an issue you can hit
whenever you use full-system suspend - it's not a problem that's unique
to Android.
--
Matthew Garrett | [email protected]
On Tue, 10 Aug 2010, Matthew Garrett wrote:
> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>>> Hmmm... Exactly which part do you consider flawed? Let's take it
>>> one sentence at a time. The devices that I know of that lack suspend
>>> blockers also lack opportunistic suspend. Therefore, all applications on
>>> such devices run as would an application that acquired a suspend blocker
>>> when it started and did not release that suspend blocker until it exited.
>>> Pretty straightforward.
>>
>> What do you mean by "opportunistic suspend", lots of systems drop into
>> lowest power states whenever they can. "Suspend is different" is a bit of
>> Android religion that I am dubious has any basis in reality as seen from
>> the application end of the universe.
>>
>> You may also wish to review the earlier parts of the discussion where it
>> was explicitly stated by several developers that they were using
>> "suspend" type modes as power states already and not using suspend
>> blockers. So it's being done, today on ARM and your statement is directly
>> contradicting the code. Modern ARM processors and x86 MID devices can
>> suspend and resume extremely fast (fast enough that the fact Linux x86
>> rewriting all the SMP alternatives on suspend/resume is a measurable
>> problem). If this same property doesn't end up on big PC boxes in time
>> then I'd be very surprised. At that point the openoffice with suspend
>> blockers or oracle with suspend blockers question becomes rather relevant.
>
> There's a clear and absolute difference between system suspend and
> entering the same hardware state from the idle loop. That difference is
> that processes aren't scheduled until an explicit wakeup event occurs.
> Android is entirely capable of entering the same low power state at idle
> (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but
> if you have more than 0 scheduling wakeups a second then your power draw
> is going to be greater.
>
> I agree that we should be targetting 0 wakeups per second. I don't agree
> that it's realistic to insist that a use model that assumes imperfect
> software is an invalid use model.
If the primary difference between sleep and suspend is not scheduling
processes, instead of messing with oppurtinistic suspend/suspend
blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz
value to a very large value (say an hour). That would still let things
like openoffice saves ahve a fair chance to trigger before the battery
died completely, but would wake the system so infrequently that it will be
effectivly the same as a full suspend.
David Lang
On Tue, Aug 10, 2010 at 11:07:20AM -0700, [email protected] wrote:
> If the primary difference between sleep and suspend is not scheduling
> processes, instead of messing with oppurtinistic suspend/suspend
> blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz
> value to a very large value (say an hour). That would still let things
> like openoffice saves ahve a fair chance to trigger before the battery
> died completely, but would wake the system so infrequently that it will
> be effectivly the same as a full suspend.
Because it only affects processes that sleep. It's a question of how
much pathology you want to be able to tolerate.
--
Matthew Garrett | [email protected]
On Tue, 10 Aug 2010, Matthew Garrett wrote:
> On Tue, Aug 10, 2010 at 11:07:20AM -0700, [email protected] wrote:
>
>> If the primary difference between sleep and suspend is not scheduling
>> processes, instead of messing with oppurtinistic suspend/suspend
>> blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz
>> value to a very large value (say an hour). That would still let things
>> like openoffice saves ahve a fair chance to trigger before the battery
>> died completely, but would wake the system so infrequently that it will
>> be effectivly the same as a full suspend.
>
> Because it only affects processes that sleep. It's a question of how
> much pathology you want to be able to tolerate.
Standard system stats will show you hogs like this. The Android people
claim that wakelock stats will let the user identify processes that
prevent the system from suspending properly and then remove them. If this
is the case, a process that never sleeps will be even easier to identify
and even more obvious an offender.
If that isn't enough, then you can go back to the other idea I advanced,
having some way to tell the system not to consider some processes when
trying to decide if the system should sleep or not.
David Lang
On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> > situation you call out can occur with manual suspend-to-RAM already:
> > the fact is that this is a design choice. You could indeed make a
>
> Losing data is a design choice ? The application set a timer, the OS
> shouldn't be ignoring it in that situation. It might want to delay it, it
> might want to warn the user its hogging things it shouldnt (powertop,
> battery usage monitors in Android etc)
Hmmm... Let's put the two approaches side by side so that we can compare
them more easily:
Opportunistic Suspend Idle + Timer Jitter
Set timer Set timer
Suspend OS delays timer
Resume OS continues delaying timer
Timer fires Timer fires
These two cases look quite similar to me.
But as you say, the battery can run out. So let's add that to the
comparison:
Opportunistic Suspend Idle + Timer Jitter
Set timer Set timer
Suspend OS delays timer
Battery runs out Battery runs out
Data loss Data loss
The two cases still look quite similar. You might note, quite correctly,
that the time between suspend and resume might be quite a bit longer than
the typical time that the OS delays a timer. But the power consumption
on some platforms is quite a bit lower in the suspend case than it is
in the delayed-timer case.
> > will by definition be the only user of that mechanism. So the fact
> > that Android is most probably the only user of suspend blockers does
> > not prove anything about whether or not suspend blockers are sensible.
>
> They don't appear to solve the constraints on power management that you
> have in other environments, nor do they happen to be conveniently
> backward compatible or available on other platforms - which makes code
> hard to port.
There does seem to be some debate (if you can call it that) over
whether suspend blockers (or something like them) apply to non-Android
environments, though I do understand that you believe that suspend blockers
are relevant only to Android. And indeed, adding features to a particular
platform can degrade portability, but the same is true of any number of
pre-existing Linux-specific features.
> > But that doesn't guarantee that solutions developed for PCs and laptops
> > will be optimal (or even usable) on cellphones. Sufficient difference
>
> Your cellphone is to all intents a laptop from ten years ago, it even has
> a similar display resolution and internet availability. The underlying
> difference between the two is solely form factor - the laptop had a
> better keyboard.
There are similarities and differences. You have called out some of
the similarities. Differences include the more-aggressive hardware
power management on cellphones, the greater number and variety of
hardware accelerators on cellphones, battery capacity, and, as you say,
physical size. People currently use cellphones differently than they
do laptops or desktops. The usage might converge, but we will see.
There is as much reason to expect increasing specialization as there
is to expect increasing convergence.
> > I hope that no one is arguing that Android will remain unchanged, just
> > as I hope no one would argue that Linux will remain unchanged. In fact,
> > I am quite confident that both Linux and Android will continue to change.
> > So exactly what point were you attempting to make here?
>
> That anything which ties to a particular style of behaviour and set of
> current usage assumptions is broken. If you rewrite all the apps to
> Android 2.1 and design in a single tasking model then you'll have to
> unrewrite half of it again when Android grows up. Ditto suspend blockers
> - encode too much policy in your apps and you lose the ability to change
> the environment under them. See the mess Microsoft got into with Win16 on
> Win32. Compare with Linux 32bit on Linux 64bit.
Yes, sooner or later, changes in environment and usage will break our
assumptions. This includes your assumptions, my assumptions, the Android
folks' assumptions, and everyone else's assumptions. We nevertheless
build things anyway.
A better comparison for Win16->Win32 would be UNIX's move from 16-bit
PDP-11 to 32-bit VAX. There was plenty of screaming over that one.
> > As to busting all apps, lthough there have been situations where busting
> > all the apps turned out to be the right thing to do, I agree that these
> > situations are extremely rare. Such situations are usually associated
> > with the emergence of a new high-volume platform.
>
> Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely
> right. It's merely that in certain cases the value in the market is large
> enough that it can be used as a big stick to beat people into doing lots
> of usually wasted work.
Interesting choice of example. I do well remember the Sequent hardware
guys' frustration when the old printer driver would monopolize the desktop
while printing their large documents. The fact was that Microsoft's
co-operative multi-tasking required all applications to be well behaved,
just as does your approach to power efficiency.
> > Hmmm... Exactly which part do you consider flawed? Let's take it
> > one sentence at a time. The devices that I know of that lack suspend
> > blockers also lack opportunistic suspend. Therefore, all applications on
> > such devices run as would an application that acquired a suspend blocker
> > when it started and did not release that suspend blocker until it exited.
> > Pretty straightforward.
>
> What do you mean by "opportunistic suspend", lots of systems drop into
> lowest power states whenever they can. "Suspend is different" is a bit of
> Android religion that I am dubious has any basis in reality as seen from
> the application end of the universe.
Opportunistic suspend has been well defined in this discussion. I do
understand that you don't like opportunistic suspend, but your distaste
for it does not undefine it.
> You may also wish to review the earlier parts of the discussion where it
> was explicitly stated by several developers that they were using
> "suspend" type modes as power states already and not using suspend
> blockers. So it's being done, today on ARM and your statement is directly
> contradicting the code. Modern ARM processors and x86 MID devices can
> suspend and resume extremely fast (fast enough that the fact Linux x86
> rewriting all the SMP alternatives on suspend/resume is a measurable
> problem). If this same property doesn't end up on big PC boxes in time
> then I'd be very surprised. At that point the openoffice with suspend
> blockers or oracle with suspend blockers question becomes rather relevant.
Here is the list of properties distinguishing idle from suspend:
1. Idle states are entered by a given CPU only there are no runnable
tasks for that CPU. In contrast, opportunistic suspend can
halt the entire system even when there are tasks that are ready,
willing, and able to run. (But please note that this might not
apply to real-time tasks.)
2. There can be a set of input events that do not bring the system
out of suspend, but which would bring the system out of idle.
Exactly which events are in this set depends both on hardware
capabilities and on the platform/application policy. For example,
on one of the Android-based smartphones, touchscreen input is
ignored when the system is suspended, but is handled when idle.
3. The system comes out of idle when a timer expires. In contrast,
timers might or might not bring the system out of suspend,
depending on both hardware capabilities and platform/application
policy.
4. Suspend generally forces devices to go into their low-power
states immediately. In contrast, idle generally leaves unused
devices at full power, relying on timers to shut down these
devices. Idle thus has shorter average wakeup latencies, but
worse energy efficiency.
5. Suspend usually has longer wakeup latency than does idle.
This list was compiled from this thread.
It is the above semantics rather than the particular C-state that makes
the difference between idle and suspend. Yes, you have claimed that
idle will render suspend obsolete, but you have not yet convinced me.
> > As for the first part of the second sentence, you yourself have argued
> > that each and every application should be carefully written to avoid
> > battery drain (or, equivalently, to promote energy efficiency), so
>
> No. I've argued that applications need to be generally well behaved, not
> keep waking up, not burn cpu - which is a generic property applicable on
> all environments not a specialisation.
Either way you prefer to word it is fine by me -- I am fine with either
"carefully written" or "generally well behaved". Alternatively, if you
were trying to say something different than what I said, I failed to
spot the difference.
> > > OpenOffice runs on netbooks, laptops, servers, even big non x86 boxes. It
> > > runs on virtual machines, it runs in power sensitive environments, it
> > > runs in thermally constrained environments, it runs in I/O constrained
> > > environments, it runs in latency constrained environments etc etc
> >
> > And there are numerous environments in which it will not run. So what?
>
> It's one codebase for all of them
Yes, and there are still numerous environments where it does not run.
> and furthermore almost all of that was
> done by modifying only the OS. Linux learned to do power throttling
> without the app being involved, it learned to do virtualisation without
> the app being changed, it is learning (with -rt) to handle to do real
> time this way.
Except that you do modify the app to more effectively throttle power.
Which is fine; I have no problem with that. I also have no problem
with things that reduce the need to modify the apps to more effectively
throttle power.
Real time indeed allows unmodified non-real-time apps to stay out of
the way of very carefully written real-time apps, so I do like that
example.
> > > All the same code, true some work has been done to make it behave
> > > politely but the rest is down to the OS doing its job - deploying the
> > > resources available while considering and obeying the constraints
> > > present, in a manner which makes best use of the resources to achieve the
> > > policy goals of the system.
> >
> > And if the work has not been done on the application, and if there is
> > nothing like suspend blockers, the OS cannot do its job.
>
> I don't see any evidence to support that claim. I see evidence that there
> are cases where apps wish to communicate their intentions around power
> more clearly but a suspend blocker is a crude single case hammer. Today
> most applications communicate their sleep/wake requirements fairly well by
> sleeping, by executing code and by setting timers/alarms.
I will take your "there are cases where apps wish to communicate their
intentions around power more clearly", thank you very much. And yes,
there is much debate over exactly what form that communication might take.
> > Given this context, are you sure that suspend blockers are not the next
> > step in the Real OS progression? Or some QoS mechanism that subsumes
> > suspend blockers? However, there is a lot of negative experience
> > around general-purpose QoS mechanisms -- you have to be quite careful
> > in order to avoid spending more energy computing QoS than you would
> > otherwise spend on the application's computations. The usual way out of
> > this trap is to abandon generality in favor of exploiting the commonly
> > occurring special cases. For all I know, raw suspend blockers might be
> > the appropriate special case.
>
> For Android possibly and I've never had any objection to Android keeping
> suspend blockers in private patches. The claim is only a small number are
> needed in their kernel so its a tiddly patch and the patch context will
> no doubt keep it applying between releases and easy for them to maintain.
>
> For the rest of us - I see no evidence it's generally useful. A QoS API
> does appear to be generally useful but as you say you need to get the
> performance right. However you can also tackle that the way we tackle
> several other examples of one interface/many needs - such as schedulers,
> security models and the like.
No one will know whether or not suspend blockers are generally useful
until they are willing to try them.
> One interface to applications and one interface to drivers so that its
> easy to maintain and you don't end up with hooks all over the place for
> different things, then if it proves neccessary different implementations.
> So yes maybe Android would use a "qos_basic" which returns -EOPNOTSUPP to
> anything but a suspend blocker behaviour. The important thing about that
> is that my device drivers, my applications and my other platforms don't
> have to care that Android made this choice - they can still be generic
> code.
If this can actually happen, I would consider it a good thing.
Of course, we might well find out some years down the road that the
qos_basic piece is the only part that was actually in common use. Then
again, it would not be the first time. System-V semaphores, anyone? ;-)
> That is why I used the Win16 example. The Win16 model encapsulated an
> implementation into the API. Had they followed a more conventional
> interface based around yielding then like MacOS they'd have had a far
> smoother move to pre-emptive MT.
I am certainly no fan of Win16. That said, if there is a qos_basic that
maps nicely to suspend blockers, the risk of adding suspend blockers in
their current form seems to me to be rather low.
Thanx, Paul
On Tue, Aug 10, 2010 at 03:44:05PM +0100, Alan Cox wrote:
> Which reminds me. I forgot a very important way that user space signals
> the kernel as to its intents.
>
> The kernel can see whether code is sleeping by choice or sleeping because
> someone blocked it (eg a page fault). The kernel also knows a lot about
> the event being waited for (much more so in -rt than base).
>
> We don't capture all of that info but it seems it would advance progress
> in the right direction to do so better.
As one approach of many, this makes a great deal of sense.
Thanx, Paul
On Tue, 10 Aug 2010, Paul E. McKenney wrote:
> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>>> situation you call out can occur with manual suspend-to-RAM already:
>>> the fact is that this is a design choice. You could indeed make a
>>
>> Losing data is a design choice ? The application set a timer, the OS
>> shouldn't be ignoring it in that situation. It might want to delay it, it
>> might want to warn the user its hogging things it shouldnt (powertop,
>> battery usage monitors in Android etc)
>
> Hmmm... Let's put the two approaches side by side so that we can compare
> them more easily:
>
> Opportunistic Suspend Idle + Timer Jitter
>
> Set timer Set timer
> Suspend OS delays timer
> Resume OS continues delaying timer
> Timer fires Timer fires
>
> These two cases look quite similar to me.
>
> But as you say, the battery can run out. So let's add that to the
> comparison:
>
> Opportunistic Suspend Idle + Timer Jitter
>
> Set timer Set timer
> Suspend OS delays timer
> Battery runs out Battery runs out
> Data loss Data loss
>
> The two cases still look quite similar. You might note, quite correctly,
> that the time between suspend and resume might be quite a bit longer than
> the typical time that the OS delays a timer. But the power consumption
> on some platforms is quite a bit lower in the suspend case than it is
> in the delayed-timer case.
it has been stated that the android can hit the exact same power state
either with sleep or suspend, and that the same clock can wake it up
(it appears as a timer expiring for sleep, or an alarm for suspend, but
it's the same clock firing the signal)
so in at least some cases the hardware supports doing both with equal
efficiency.
>>> But that doesn't guarantee that solutions developed for PCs and laptops
>>> will be optimal (or even usable) on cellphones. Sufficient difference
>>
>> Your cellphone is to all intents a laptop from ten years ago, it even has
>> a similar display resolution and internet availability. The underlying
>> difference between the two is solely form factor - the laptop had a
>> better keyboard.
>
> There are similarities and differences. You have called out some of
> the similarities. Differences include the more-aggressive hardware
> power management on cellphones, the greater number and variety of
> hardware accelerators on cellphones, battery capacity, and, as you say,
> physical size. People currently use cellphones differently than they
> do laptops or desktops. The usage might converge, but we will see.
> There is as much reason to expect increasing specialization as there
> is to expect increasing convergence.
You are talking about Android as if it was a cell phone only thing, it's
not. there are shipping tablets (and I believe netbooks, i.e. laptops)
running andoid.
>>> As to busting all apps, lthough there have been situations where busting
>>> all the apps turned out to be the right thing to do, I agree that these
>>> situations are extremely rare. Such situations are usually associated
>>> with the emergence of a new high-volume platform.
>>
>> Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely
>> right. It's merely that in certain cases the value in the market is large
>> enough that it can be used as a big stick to beat people into doing lots
>> of usually wasted work.
>
> Interesting choice of example. I do well remember the Sequent hardware
> guys' frustration when the old printer driver would monopolize the desktop
> while printing their large documents. The fact was that Microsoft's
> co-operative multi-tasking required all applications to be well behaved,
> just as does your approach to power efficiency.
and wakelocks require all applications that can take a wakelock be well
behaved. and applications that do nt take a wakelock directly cannot
expect to run unless something else takes a wakelock on their behalf
David Lang
On Tuesday, August 10, 2010, Arve Hj?nnev?g wrote:
> 2010/8/9 Rafael J. Wysocki <[email protected]>:
> > On Monday, August 09, 2010, Arve Hj?nnev?g wrote:
...
>
> > Anyway, as I said I'm not opposed to the idea of using a special type of
> > objects for collecting debug information on wakeup events, so please free to
> > submit patches modifying the current mainline kernel code in that direction.
> >
>
> How do you prefer to handle your pci wakeup events? Add a handle to
> every device or pci device? Or use a global handle to avoid the race
> and report wakeup events for debugging separately?
The latter, maybe?
Thanks,
Rafael
On Tue, Aug 10, 2010 at 06:28:39PM -0700, [email protected] wrote:
> On Tue, 10 Aug 2010, Paul E. McKenney wrote:
>
> >On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> >>>situation you call out can occur with manual suspend-to-RAM already:
> >>>the fact is that this is a design choice. You could indeed make a
> >>
> >>Losing data is a design choice ? The application set a timer, the OS
> >>shouldn't be ignoring it in that situation. It might want to delay it, it
> >>might want to warn the user its hogging things it shouldnt (powertop,
> >>battery usage monitors in Android etc)
> >
> >Hmmm... Let's put the two approaches side by side so that we can compare
> >them more easily:
> >
> > Opportunistic Suspend Idle + Timer Jitter
> >
> > Set timer Set timer
> > Suspend OS delays timer
> > Resume OS continues delaying timer
> > Timer fires Timer fires
> >
> >These two cases look quite similar to me.
> >
> >But as you say, the battery can run out. So let's add that to the
> >comparison:
> >
> > Opportunistic Suspend Idle + Timer Jitter
> >
> > Set timer Set timer
> > Suspend OS delays timer
> > Battery runs out Battery runs out
> > Data loss Data loss
> >
> >The two cases still look quite similar. You might note, quite correctly,
> >that the time between suspend and resume might be quite a bit longer than
> >the typical time that the OS delays a timer. But the power consumption
> >on some platforms is quite a bit lower in the suspend case than it is
> >in the delayed-timer case.
>
> it has been stated that the android can hit the exact same power
> state either with sleep or suspend, and that the same clock can wake
> it up (it appears as a timer expiring for sleep, or an alarm for
> suspend, but it's the same clock firing the signal)
>
> so in at least some cases the hardware supports doing both with
> equal efficiency.
It indeed has been so stated. But in this section we were discussing
data loss, not hardware power-state capabilities.
> >>>But that doesn't guarantee that solutions developed for PCs and laptops
> >>>will be optimal (or even usable) on cellphones. Sufficient difference
> >>
> >>Your cellphone is to all intents a laptop from ten years ago, it even has
> >>a similar display resolution and internet availability. The underlying
> >>difference between the two is solely form factor - the laptop had a
> >>better keyboard.
> >
> >There are similarities and differences. You have called out some of
> >the similarities. Differences include the more-aggressive hardware
> >power management on cellphones, the greater number and variety of
> >hardware accelerators on cellphones, battery capacity, and, as you say,
> >physical size. People currently use cellphones differently than they
> >do laptops or desktops. The usage might converge, but we will see.
> >There is as much reason to expect increasing specialization as there
> >is to expect increasing convergence.
>
> You are talking about Android as if it was a cell phone only thing,
> it's not. there are shipping tablets (and I believe netbooks, i.e.
> laptops) running andoid.
I was talking about cellphones. But yes, Android (and thus suspend
blockers) are used for tablets as well as cellphones, thank you for
reminding me!
> >>>As to busting all apps, lthough there have been situations where busting
> >>>all the apps turned out to be the right thing to do, I agree that these
> >>>situations are extremely rare. Such situations are usually associated
> >>>with the emergence of a new high-volume platform.
> >>
> >>Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely
> >>right. It's merely that in certain cases the value in the market is large
> >>enough that it can be used as a big stick to beat people into doing lots
> >>of usually wasted work.
> >
> >Interesting choice of example. I do well remember the Sequent hardware
> >guys' frustration when the old printer driver would monopolize the desktop
> >while printing their large documents. The fact was that Microsoft's
> >co-operative multi-tasking required all applications to be well behaved,
> >just as does your approach to power efficiency.
>
> and wakelocks require all applications that can take a wakelock be
> well behaved. and applications that do nt take a wakelock directly
> cannot expect to run unless something else takes a wakelock on their
> behalf
Almost. Suspend blockers require that only those portions of a PM-driving
application that hold a suspend blocker be carefully written to avoid
wasting power.
Thanx, Paul
On Tue, 10 Aug 2010, Paul E. McKenney wrote:
> Subject: Re: Attempted summary of suspend-blockers LKML thread, take three
>
> On Tue, Aug 10, 2010 at 06:28:39PM -0700, [email protected] wrote:
>> On Tue, 10 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>>>>> situation you call out can occur with manual suspend-to-RAM already:
>>>>> the fact is that this is a design choice. You could indeed make a
>>>>
>>>> Losing data is a design choice ? The application set a timer, the OS
>>>> shouldn't be ignoring it in that situation. It might want to delay it, it
>>>> might want to warn the user its hogging things it shouldnt (powertop,
>>>> battery usage monitors in Android etc)
>>>
>>> Hmmm... Let's put the two approaches side by side so that we can compare
>>> them more easily:
>>>
>>> Opportunistic Suspend Idle + Timer Jitter
>>>
>>> Set timer Set timer
>>> Suspend OS delays timer
>>> Resume OS continues delaying timer
>>> Timer fires Timer fires
>>>
>>> These two cases look quite similar to me.
>>>
>>> But as you say, the battery can run out. So let's add that to the
>>> comparison:
>>>
>>> Opportunistic Suspend Idle + Timer Jitter
>>>
>>> Set timer Set timer
>>> Suspend OS delays timer
>>> Battery runs out Battery runs out
>>> Data loss Data loss
>>>
>>> The two cases still look quite similar. You might note, quite correctly,
>>> that the time between suspend and resume might be quite a bit longer than
>>> the typical time that the OS delays a timer. But the power consumption
>>> on some platforms is quite a bit lower in the suspend case than it is
>>> in the delayed-timer case.
>>
>> it has been stated that the android can hit the exact same power
>> state either with sleep or suspend, and that the same clock can wake
>> it up (it appears as a timer expiring for sleep, or an alarm for
>> suspend, but it's the same clock firing the signal)
>>
>> so in at least some cases the hardware supports doing both with
>> equal efficiency.
>
> It indeed has been so stated. But in this section we were discussing
> data loss, not hardware power-state capabilities.
you specifically stated that suspend would use less power. I am pointing
out that ther is info posed in this thread to say that's not always the
case.
in either case it is possible for the system to wake up again later to let
the timer fire and the application save it's work. It's arguably easier
in the idle case as it doesn't require application modification
for example
Idle + Timer Jitter
set timer
OS sets timer jitter to 1 hour
system sleeps for 1 hour with no wakeups
timer fires, applications wake and process data
system sleeps (for 1 hour or more with no wakeups)
(repeat as needed until battery runs out)
much less chance for data loss as there is _far_ more of a chance that the
timer
waking up once per hour for a short time is not going to make a noticable
difference in your total battery life of a cell phone due to the
significant idle power draw needed for the cell circuitry. On something
like a e-reader with no radio link and a month-long idle time it could
make a difference.
note that this is with a badly written app running that is trying to
wakeup repeatedly. If the app is well behaved and only schedule a timer
when they will have work to do, they may not schedule a timer at all after
the data is saved, and so would have the data safe and just as long a
standby time.
>>>>> But that doesn't guarantee that solutions developed for PCs and laptops
>>>>> will be optimal (or even usable) on cellphones. Sufficient difference
>>>>
>>>> Your cellphone is to all intents a laptop from ten years ago, it even has
>>>> a similar display resolution and internet availability. The underlying
>>>> difference between the two is solely form factor - the laptop had a
>>>> better keyboard.
>>>
>>> There are similarities and differences. You have called out some of
>>> the similarities. Differences include the more-aggressive hardware
>>> power management on cellphones, the greater number and variety of
>>> hardware accelerators on cellphones, battery capacity, and, as you say,
>>> physical size. People currently use cellphones differently than they
>>> do laptops or desktops. The usage might converge, but we will see.
>>> There is as much reason to expect increasing specialization as there
>>> is to expect increasing convergence.
>>
>> You are talking about Android as if it was a cell phone only thing,
>> it's not. there are shipping tablets (and I believe netbooks, i.e.
>> laptops) running andoid.
>
> I was talking about cellphones. But yes, Android (and thus suspend
> blockers) are used for tablets as well as cellphones, thank you for
> reminding me!
the fact that it's used there means that you can't argue that it's
difference because cell phones are so different (unless you are saying
that Android is really not appropriate for those uses)
On the other hand, lots of things are used in places where it is
inappropriate, Windows CE is used on phones, tablets, etc but I think most
people would say that the use of windows there isn't appropriate.
David Lang
On Mon, Aug 9, 2010 at 12:38 AM, Ted Ts'o <[email protected]> wrote:
> On Sun, Aug 08, 2010 at 08:40:28PM +0300, Felipe Contreras wrote:
>>
>> My guess is you haven't used a truly multi-tasking device like the
>> N900; now that I've got used to it, I consider that functionality
>> *essential*.
>
> I've used an N800, and I wasn't impressed; if anything, the fact that
> I have to worry about manually killing off applications when memory
> gets low, I actually thought it was incredibly sucky. It was a
> miniature, badly done laptop.
>
> Maybe the N900 is different, but the bigger question is what do you
> mean by "multi-tasking"? Definitions are critical here, which is why
> Paul was so careful in his definitions section of his document.
Yes, the N900 is drastically different, for starters, it has an actual
window manager.
By multi-tasking I mean me (the user) being able to perform multiple
tasks at the same time.
For example: writing an email, while browsing the web, while having IM
conversations. Obviously not exactly at the same time; start writing
an email, go browse for some url, copy, answer a pending IM message,
go back to the mail, paste.
>> The argument in favor of suspend blockers is that you could take
>> applications that are not designed for embedded, and make them run on
>> an embedded device without draining excessive battery life; those
>> applications would have to be background services not conflicting with
>> Android's design.
>>
>> I agree there probably would not be that many background apps, and
>> probably even less ported background apps, but that is actually an
>> argument against suspend blockers.
>>
>> The rest of the apps (UI apps), cannot be ported, but have to be
>> written specifically for Android, and therefore should have PM in
>> mind, and not require suspend blockers to have good power usage.
>
> If you are using a GUI framework which is optimized for a single-
> application-focus-at-a-time UI that isn't GNOME or KDE, then that will
> require the applications to be written. However, that's not because
> of suspend-blockers.
Let's concentrate; Android is the only mobile platform that has
expressed interested in suspend blockers. UI applications in Android
are written specifically for Android. Period.
Other platforms, such as MeeGo, rely on Qt API, not suspend blockers.
> If you assume a GUI framework which is flexible enough --- maybe Qt
> falls into this category, maybe not --- for the rest of the
> applications, they don't need to *know* about suspend blockers, and
> they certainly do't have to be rewritten or modified specifically for
> suspend blockers. So if your argument is that applications that don't
> need bacground services (which you've admitted comprises majority of
> applicatios) need to be modified or written specifically to support
> suspend blockers, that's simply not true. They don't need to be
> modified at all.
That's not my argument at all. I was talking about a counter-argument
to "suspend blockers make porting desktop apps easer".
Android's UI applications are unimportant here because they have not
been ported from the desktop realm; they were designed specifically
for Android, including all its PM capabilities.
The only relevant applications are the ones designed for the desktop
that are ported to Android, and thus might make assumptions that hurt
battery life. These are background services.
If you are saying that there are few background apps, then that's an
argument against suspend blockers:
1) few applications can be ported
2) the few applications that can be ported, being background
services, might miss timers and behave worst than _without_ suspend
blockers
> As far as whether they *should* require suspend blockers to be in the
> kernel to get power usage that is suitable for cell phone batteries, I
> would agree that in the ideal world, it would be nice if you could
> have applications that make the correct performance/battery
> utilization tradeoff for devices running on 800 mWh batteries, 94,000
> mWh batteries, and while running on the AC mains. But I don't believe
> that it's likely to be true, and if you want to try to beat up on
> application writers one at a time to be power optimized --- as far as
> I'm concerned, that's an argument *for* suspend blockers, since I'm
> not big believer in plans that begin, "First, you command the tides of
> the sea to go back", King Canute style. :-)
Power is just like any other resource, why are desktop applications
not using 100% CPU, or 100% of memory? Because if they did nobody
would be using them. There's a social pressure to use less resources,
or at least less resources than the competence. If an application uses
too much battery time nobody would use it, unless perhaps if the
functionality is too good and there are no alternatives.
I believe social forces already deal with this problem, all we need to
do is provide better tools, not patronize user-space applications.
--
Felipe Contreras
On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
<[email protected]> wrote:
> But wouldn't an office suite run as a power-oblivious application on an
> Android device? After all, office applications do not need to run when
> the screen is turned off, so these the applications do not need to use
> suspend blockers.
Ideally the system would be suspended even when the screen is on. If
there are no "trusted" applications running at the same time, then
openoffice wouldn't load at all. Right?
--
Felipe Contreras
On Tue, Aug 10, 2010 at 7:45 AM, Paul E. McKenney
<[email protected]> wrote:
> On Mon, Aug 09, 2010 at 08:18:22PM +0100, Alan Cox wrote:
>> You are tightly linking suspend blockers with Android. If they were a
>> sensible general solution they would be generic not tied closely to
>> Android
>
> Android is certainly where suspend blockers originated, and is to the best
> of my knowledge is still the only platform that uses them. But there is
> a first user of every new mechanism, and for some time that first user
> will by definition be the only user of that mechanism. So the fact
> that Android is most probably the only user of suspend blockers does
> not prove anything about whether or not suspend blockers are sensible.
No, it's the fact that *nobody* else has said: hey, that looks like a
good idea, we should use that in our mobile platform (or any
platform).
--
Felipe Contreras
On Wed, Aug 11, 2010 at 07:57:32PM +0300, Felipe Contreras wrote:
> Let's concentrate; Android is the only mobile platform that has
> expressed interested in suspend blockers. UI applications in Android
> are written specifically for Android. Period.
>
> Other platforms, such as MeeGo, rely on Qt API, not suspend blockers.
I think you're wrong that this will be sufficient, but I've already
stated my position before, namely that what you do when you only have
800mWh has very different performance/battery tradeoffs than when you
have 94,000mWh batteries. One of the reasons why my mail archive for
this discussion has over 1800 messages and is close to 10MB is that
everyone keeps saying the same thing over and over again. So I'm not
going to say it again.
I was thinking that the only way we can tell is for us to go away and
come back in two years, and we can see whether or not Meego is getting
the same 200,000 activations per day that Android is, and maybe *then*
people will understand.
However, earlier today, I had a very productive conversation with an
engineer from Nokia who has had many years of experience of doing
power management for cell phones, and who is now trying to make Meego
power efficient enough for cell phones, and he seemed to think that
problem which suspend blockers or wakelocks are trying to solve was
valid.
I now believe that part of the problem is that is that many Meego
folks only have an experience with Netbooks or Laptops, and don't
appreciate that sometimes, when you make such a radical change in
battery capacity to a mobile handset, things become qualitatively
different, and not just quantitatively different. Put another way, a
laptop has six hours of battery lifetime with 94,000 mWh worth of
battery; a cell phone needs to be able to be usable over a 20-24 hour
period of despite having a 800-1200 mWh battery --- and what you need
do for these two are different.
This is very similar to how trying to make a kernel scale to 512 NUMA
nodes is quite different to trying make a kernel work with 4-8 SMP
cpu's. Until you've actually tried doing it, you might think that all
you have to do is just throw in a bunch of spinlocks and rw spinlocks.
But it turns out it's a lot harder than that --- but it's very hard to
convince someone who hasn't had that experience to understand why that
is true.
So it may very well be that we should just agree to disagree, and if
there are one or more Nokia engineers who are interested in doing
something that would help their cell phones (I will let them speak up
and clarify their positions for themselves), that they work directly
with those who agree that there _is_ a problem.
At that point, we can either keep these patches out of tree, much like
how the SGI Altix has patches that are needed so that the Linux kernel
scales enough so it will even successfully complete its kernel
initialization successfully. Or if there is consensus between people
who are interested at Linaro (if any), Nokia (if any), and Android (if
any), maybe we take this directly to Linus, and he can say yes or no.
But for those who are unwilling to believe it isn't even a problem, I
don't know that another 2000 e-mail messages, and another 10MB of mail
archives, is going to achieve anything. Let's just agree to disagree.
- Ted
P.S. Just to make it clear, I am speaking only for myself, and not
for the Android team and not for Google in any way, shape, or form.
Nor was the person from Nokia who expressed to me his opinions was not
necessarily expressing the opinions of Nokia or (obviously) Meego.
On Wed, Aug 11, 2010 at 10:25:04PM +0300, Felipe Contreras wrote:
> On Tue, Aug 10, 2010 at 7:45 AM, Paul E. McKenney
> > Android is certainly where suspend blockers originated, and is to the best
> > of my knowledge is still the only platform that uses them. ??But there is
> > a first user of every new mechanism, and for some time that first user
> > will by definition be the only user of that mechanism. ??So the fact
> > that Android is most probably the only user of suspend blockers does
> > not prove anything about whether or not suspend blockers are sensible.
> No, it's the fact that *nobody* else has said: hey, that looks like a
> good idea, we should use that in our mobile platform (or any
> platform).
I don't think lack of external adoption is a terribly useful data point
either way at the minute. While the feature is controversial a lot of
the OSs will probably hold off on it (because it's effort to handle out
of tree stuff and folks are really busy) and there's not that many out
there which support random externally written packages (which is the
major push for exporting the feature to userspace) in the first place.
On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney
<[email protected]> wrote:
> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>> You may also wish to review the earlier parts of the discussion where it
>> was explicitly stated by several developers that they were using
>> "suspend" type modes as power states already and not using suspend
>> blockers. So it's being done, today on ARM and your statement is directly
>> contradicting the code. Modern ARM processors and x86 MID devices can
>> suspend and resume extremely fast (fast enough that the fact Linux x86
>> rewriting all the SMP alternatives on suspend/resume is a measurable
>> problem). If this same property doesn't end up on big PC boxes in time
>> then I'd be very surprised. At that point the openoffice with suspend
>> blockers or oracle with suspend blockers question becomes rather relevant.
>
> Here is the list of properties distinguishing idle from suspend:
>
> 1. Idle states are entered by a given CPU only there are no runnable
> tasks for that CPU. In contrast, opportunistic suspend can
> halt the entire system even when there are tasks that are ready,
> willing, and able to run. (But please note that this might not
> apply to real-time tasks.)
But if there are no runnable tasks (which is the target), they behave the same.
> 2. There can be a set of input events that do not bring the system
> out of suspend, but which would bring the system out of idle.
> Exactly which events are in this set depends both on hardware
> capabilities and on the platform/application policy. For example,
> on one of the Android-based smartphones, touchscreen input is
> ignored when the system is suspended, but is handled when idle.
And in N900 touching the screen doesn't bring the device out of idle,
I guess because it's off.
What devices do what on which circumstances on what platform is
completely irrelevant.
> 3. The system comes out of idle when a timer expires. In contrast,
> timers might or might not bring the system out of suspend,
> depending on both hardware capabilities and platform/application
> policy.
Isn't this solved by range timers?
> 4. Suspend generally forces devices to go into their low-power
> states immediately. In contrast, idle generally leaves unused
> devices at full power, relying on timers to shut down these
> devices. Idle thus has shorter average wakeup latencies, but
> worse energy efficiency.
Only if you make these assumptions
1) All the applications use suspend-blockers only when they absolutely must
2) The user has given the right applications the right access
If not, you'll see much worst energy efficiency. So in theory maybe,
but in practice you can't say that.
--
Felipe Contreras
On Wed, Aug 11, 2010 at 10:31 PM, Ted Ts'o <[email protected]> wrote:
> On Wed, Aug 11, 2010 at 07:57:32PM +0300, Felipe Contreras wrote:
>> Let's concentrate; Android is the only mobile platform that has
>> expressed interested in suspend blockers. UI applications in Android
>> are written specifically for Android. Period.
>>
>> Other platforms, such as MeeGo, rely on Qt API, not suspend blockers.
>
> I think you're wrong that this will be sufficient, but I've already
> stated my position before, namely that what you do when you only have
> 800mWh has very different performance/battery tradeoffs than when you
> have 94,000mWh batteries. One of the reasons why my mail archive for
> this discussion has over 1800 messages and is close to 10MB is that
> everyone keeps saying the same thing over and over again. So I'm not
> going to say it again.
Applications need to take smart decisions to save power based on a
number of things: is the screen on? is the ear close to the speaker?
is there a network available? is it a cellular connection? has the
user decided to automatically disconnect from the network after
certain time, or at night? etc. I think that, and range timers / ip
heartbeat is enough. But that, as you say has been discussed before.
Now, only Android has decided to use suspend blockers, that's a
*fact*, and I wanted to narrow the discussion to Android in order to
make it easier to understand that Android doesn't need suspend
blockers, once we have agreed that, then I'd gladly discuss it's
merits outside Android.
> I was thinking that the only way we can tell is for us to go away and
> come back in two years, and we can see whether or not Meego is getting
> the same 200,000 activations per day that Android is, and maybe *then*
> people will understand.
Are you kidding? Even if MeeGo fails in being as popular as Android,
that doesn't saying anything about whether suspend-blockers are
sensible or not. Besides, there is also the possibility that Android
people realize they don't need suspend-blockers.
> However, earlier today, I had a very productive conversation with an
> engineer from Nokia who has had many years of experience of doing
> power management for cell phones, and who is now trying to make Meego
> power efficient enough for cell phones, and he seemed to think that
> problem which suspend blockers or wakelocks are trying to solve was
> valid.
So? I'm sure there's some people in Google that believe that
suspend-blockers are not needed.
> I now believe that part of the problem is that is that many Meego
> folks only have an experience with Netbooks or Laptops, and don't
> appreciate that sometimes, when you make such a radical change in
> battery capacity to a mobile handset, things become qualitatively
> different, and not just quantitatively different. Put another way, a
> laptop has six hours of battery lifetime with 94,000 mWh worth of
> battery; a cell phone needs to be able to be usable over a 20-24 hour
> period of despite having a 800-1200 mWh battery --- and what you need
> do for these two are different.
Right. Nokia people only have experience with laptops. Surely my N900
lasts days because it's receiving energy from another dimension.
> This is very similar to how trying to make a kernel scale to 512 NUMA
> nodes is quite different to trying make a kernel work with 4-8 SMP
> cpu's. Until you've actually tried doing it, you might think that all
> you have to do is just throw in a bunch of spinlocks and rw spinlocks.
> But it turns out it's a lot harder than that --- but it's very hard to
> convince someone who hasn't had that experience to understand why that
> is true.
We are talking about user-space.
> So it may very well be that we should just agree to disagree, and if
> there are one or more Nokia engineers who are interested in doing
> something that would help their cell phones (I will let them speak up
> and clarify their positions for themselves), that they work directly
> with those who agree that there _is_ a problem.
Yeah, there is a problem, and the solution doesn't require suspend-blockers.
> At that point, we can either keep these patches out of tree, much like
> how the SGI Altix has patches that are needed so that the Linux kernel
> scales enough so it will even successfully complete its kernel
> initialization successfully. Or if there is consensus between people
> who are interested at Linaro (if any), Nokia (if any), and Android (if
> any), maybe we take this directly to Linus, and he can say yes or no.
>
> But for those who are unwilling to believe it isn't even a problem, I
> don't know that another 2000 e-mail messages, and another 10MB of mail
> archives, is going to achieve anything. Let's just agree to disagree.
I argued to you that suspend-blockers are not required in Android, and
suddenly you decide we should agree to disagree without arguing back?
Well, suit yourself. I still maintain that suspend-blockers is just an
expensive workaround, and in some cases actually degrades power
consumption; the right solution is much more sophisticated.
--
Felipe Contreras
On Wed, Aug 11, 2010 at 2:25 PM, Felipe Contreras
<[email protected]> wrote:
> Now, only Android has decided to use suspend blockers, that's a
> *fact*, and I wanted to narrow the discussion to Android in order to
> make it easier to understand that Android doesn't need suspend
> blockers, once we have agreed that, then I'd gladly discuss it's
> merits outside Android.
On behalf of the Android folks, we don't agree with this. If you're
going to wait until we suddenly change our minds, I think you're going
to be in for a long wait.
> I argued to you that suspend-blockers are not required in Android, and
> suddenly you decide we should agree to disagree without arguing back?
> Well, suit yourself. I still maintain that suspend-blockers is just an
> expensive workaround, and in some cases actually degrades power
> consumption; the right solution is much more sophisticated.
Once "the right solution" exists and solves our problems, we'll
certainly look into switching over to it. I've yet to see a proposal
in all this arguing that appears to me to be an improvement over what
we have today with suspend blockers. I find the "don't do what you're
doing because someday, somebody will do it better" to be an
uncompelling argument.
Given your opinion that Android lacks multitasking (what? really?) and
various other strange statements about the platform, I'm likely to be
taking your suggestions with generous helping of skepticism.
Brian
On Thu, Aug 12, 2010 at 12:37 AM, Brian Swetland <[email protected]> wrote:
> On Wed, Aug 11, 2010 at 2:25 PM, Felipe Contreras
> <[email protected]> wrote:
>> Now, only Android has decided to use suspend blockers, that's a
>> *fact*, and I wanted to narrow the discussion to Android in order to
>> make it easier to understand that Android doesn't need suspend
>> blockers, once we have agreed that, then I'd gladly discuss it's
>> merits outside Android.
>
> On behalf of the Android folks, we don't agree with this. If you're
> going to wait until we suddenly change our minds, I think you're going
> to be in for a long wait.
I'm sure as a team that's the case, but you can't know what's in the
mind of everyone at Google (not Android).
>> I argued to you that suspend-blockers are not required in Android, and
>> suddenly you decide we should agree to disagree without arguing back?
>> Well, suit yourself. I still maintain that suspend-blockers is just an
>> expensive workaround, and in some cases actually degrades power
>> consumption; the right solution is much more sophisticated.
>
> Once "the right solution" exists and solves our problems, we'll
> certainly look into switching over to it. I've yet to see a proposal
> in all this arguing that appears to me to be an improvement over what
> we have today with suspend blockers. I find the "don't do what you're
> doing because someday, somebody will do it better" to be an
> uncompelling argument.
That was not an argument, it was an opinion. If you want an argument
go back to read this one:
http://article.gmane.org/gmane.linux.kernel/1021834
> Given your opinion that Android lacks multitasking (what? really?)
This is what I'm talking about when I say multi-tasking, Android
certainly doesn't have anything remotely like that:
http://www.youtube.com/watch?v=7emvUBpEkbU
--
Felipe Contreras
On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras
<[email protected]> wrote:
>> Once "the right solution" exists and solves our problems, we'll
>> certainly look into switching over to it. I've yet to see a proposal
>> in all this arguing that appears to me to be an improvement over what
>> we have today with suspend blockers. I find the "don't do what you're
>> doing because someday, somebody will do it better" to be an
>> uncompelling argument.
>
> That was not an argument, it was an opinion. If you want an argument
> go back to read this one:
> http://article.gmane.org/gmane.linux.kernel/1021834
>
>> Given your opinion that Android lacks multitasking (what? really?)
>
> This is what I'm talking about when I say multi-tasking, Android
> certainly doesn't have anything remotely like that:
> http://www.youtube.com/watch?v=7emvUBpEkbU
Home + pick app -> switch to the app in whatever state it was in.
Home (longpress) -> recent app list + pick app from popup -> switch to
recent app in whatever state it was in.
pull down alert windowshade + pick app from alerts list -> switch to that app
I routinely flip back and forth between email / browser / IM / musicplayer / etc
I have no problem with you perhaps liking the visuals of the N900
better, but to say Android lacks multitasking (as you explain it
below) is incorrect:
> By multi-tasking I mean me (the user) being able to perform multiple
> tasks at the same time.
> For example: writing an email, while browsing the web, while having IM
> conversations. Obviously not exactly at the same time; start writing
> an email, go browse for some url, copy, answer a pending IM message,
> go back to the mail, paste.
As far as implementing app switching with a deck of cards metaphor,
I've seen that done by some OEMs with Android, though it's not the
default system UI.
Brian
On Wed, Aug 11, 2010 at 11:00:42PM +0300, Felipe Contreras wrote:
> On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney
> <[email protected]> wrote:
> > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> >> You may also wish to review the earlier parts of the discussion where it
> >> was explicitly stated by several developers that they were using
> >> "suspend" type modes as power states already and not using suspend
> >> blockers. So it's being done, today on ARM and your statement is directly
> >> contradicting the code. Modern ARM processors and x86 MID devices can
> >> suspend and resume extremely fast (fast enough that the fact Linux x86
> >> rewriting all the SMP alternatives on suspend/resume is a measurable
> >> problem). If this same property doesn't end up on big PC boxes in time
> >> then I'd be very surprised. At that point the openoffice with suspend
> >> blockers or oracle with suspend blockers question becomes rather relevant.
> >
> > Here is the list of properties distinguishing idle from suspend:
> >
> > 1. ? ? ?Idle states are entered by a given CPU only there are no runnable
> > ? ? ? ?tasks for that CPU. ?In contrast, opportunistic suspend can
> > ? ? ? ?halt the entire system even when there are tasks that are ready,
> > ? ? ? ?willing, and able to run. ?(But please note that this might not
> > ? ? ? ?apply to real-time tasks.)
>
> But if there are no runnable tasks (which is the target), they behave the same.
And if there are runnable tasks, then then don't behave the same.
Apparently different people in this debate have different targets.
> > 2. ? ? ?There can be a set of input events that do not bring the system
> > ? ? ? ?out of suspend, but which would bring the system out of idle.
> > ? ? ? ?Exactly which events are in this set depends both on hardware
> > ? ? ? ?capabilities and on the platform/application policy. ?For example,
> > ? ? ? ?on one of the Android-based smartphones, touchscreen input is
> > ? ? ? ?ignored when the system is suspended, but is handled when idle.
>
> And in N900 touching the screen doesn't bring the device out of idle,
> I guess because it's off.
As long as touching the N900 screen doesn't bring the device out of
suspend, its behavior is not a counterexample to #2 above.
> What devices do what on which circumstances on what platform is
> completely irrelevant.
Do you -really- want me to start listing counterexamples to that
brave statement? ;-)
> > 3. ? ? ?The system comes out of idle when a timer expires. ?In contrast,
> > ? ? ? ?timers might or might not bring the system out of suspend,
> > ? ? ? ?depending on both hardware capabilities and platform/application
> > ? ? ? ?policy.
>
> Isn't this solved by range timers?
Ahem. This is a list of differences between idle and suspend, not
a list of problems to be solved. But to answer your question, if a
timer does not bring a given device out of suspend, then a range timer
is not likely to, either. Don't get me wrong, I do believe that range
timers have an important part to play in the energy-efficiency arena,
but I have not been convinced that they are any kind of silver bullet.
> > 4. ? ? ?Suspend generally forces devices to go into their low-power
> > ? ? ? ?states immediately. ?In contrast, idle generally leaves unused
> > ? ? ? ?devices at full power, relying on timers to shut down these
> > ? ? ? ?devices. ?Idle thus has shorter average wakeup latencies, but
> > ? ? ? ?worse energy efficiency.
>
> Only if you make these assumptions
> 1) All the applications use suspend-blockers only when they absolutely must
> 2) The user has given the right applications the right access
You believe that these assumptions are unreasonable? Compared to the
assumption that all applications are carefully written to conserve power?
If so, on what grounds?
It seems to me that the same social-engineering approaches work in
both cases.
> If not, you'll see much worst energy efficiency. So in theory maybe,
> but in practice you can't say that.
Really? What makes you say that?
Thanx, Paul
On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote:
> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
> <[email protected]> wrote:
> > But wouldn't an office suite run as a power-oblivious application on an
> > Android device? ?After all, office applications do not need to run when
> > the screen is turned off, so these the applications do not need to use
> > suspend blockers.
>
> Ideally the system would be suspended even when the screen is on. If
> there are no "trusted" applications running at the same time, then
> openoffice wouldn't load at all. Right?
My understanding is that Android systems in fact do not suspend when
the screen is on, and that most (perhaps all) other systems do not
opportunistically suspend at all. There has been some speculation about
what a hypothetical Android having a non-volatile display might do,
but as far as I know, this is just speculation.
Thanx, Paul
On Tue, Aug 10, 2010 at 08:00:53PM -0700, [email protected] wrote:
> On Tue, 10 Aug 2010, Paul E. McKenney wrote:
>
> >Subject: Re: Attempted summary of suspend-blockers LKML thread, take three
> >
> >On Tue, Aug 10, 2010 at 06:28:39PM -0700, [email protected] wrote:
> >>On Tue, 10 Aug 2010, Paul E. McKenney wrote:
> >>
> >>>On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> >>>>>situation you call out can occur with manual suspend-to-RAM already:
> >>>>>the fact is that this is a design choice. You could indeed make a
> >>>>
> >>>>Losing data is a design choice ? The application set a timer, the OS
> >>>>shouldn't be ignoring it in that situation. It might want to delay it, it
> >>>>might want to warn the user its hogging things it shouldnt (powertop,
> >>>>battery usage monitors in Android etc)
> >>>
> >>>Hmmm... Let's put the two approaches side by side so that we can compare
> >>>them more easily:
> >>>
> >>> Opportunistic Suspend Idle + Timer Jitter
> >>>
> >>> Set timer Set timer
> >>> Suspend OS delays timer
> >>> Resume OS continues delaying timer
> >>> Timer fires Timer fires
> >>>
> >>>These two cases look quite similar to me.
> >>>
> >>>But as you say, the battery can run out. So let's add that to the
> >>>comparison:
> >>>
> >>> Opportunistic Suspend Idle + Timer Jitter
> >>>
> >>> Set timer Set timer
> >>> Suspend OS delays timer
> >>> Battery runs out Battery runs out
> >>> Data loss Data loss
> >>>
> >>>The two cases still look quite similar. You might note, quite correctly,
> >>>that the time between suspend and resume might be quite a bit longer than
> >>>the typical time that the OS delays a timer. But the power consumption
> >>>on some platforms is quite a bit lower in the suspend case than it is
> >>>in the delayed-timer case.
> >>
> >>it has been stated that the android can hit the exact same power
> >>state either with sleep or suspend, and that the same clock can wake
> >>it up (it appears as a timer expiring for sleep, or an alarm for
> >>suspend, but it's the same clock firing the signal)
> >>
> >>so in at least some cases the hardware supports doing both with
> >>equal efficiency.
> >
> >It indeed has been so stated. But in this section we were discussing
> >data loss, not hardware power-state capabilities.
>
> you specifically stated that suspend would use less power. I am
> pointing out that ther is info posed in this thread to say that's
> not always the case.
I specifically stated something different, and if you specifically look
up a few paragraph, you will specifically see that I specifically used
a specific qualifier, which you specifically seem to have lost track of.
;-), Paul
> in either case it is possible for the system to wake up again later
> to let the timer fire and the application save it's work. It's
> arguably easier in the idle case as it doesn't require application
> modification
>
> for example
>
> Idle + Timer Jitter
> set timer
> OS sets timer jitter to 1 hour
> system sleeps for 1 hour with no wakeups
> timer fires, applications wake and process data
> system sleeps (for 1 hour or more with no wakeups)
> (repeat as needed until battery runs out)
>
> much less chance for data loss as there is _far_ more of a chance
> that the timer
>
> waking up once per hour for a short time is not going to make a
> noticable difference in your total battery life of a cell phone due
> to the significant idle power draw needed for the cell circuitry. On
> something like a e-reader with no radio link and a month-long idle
> time it could make a difference.
>
> note that this is with a badly written app running that is trying to
> wakeup repeatedly. If the app is well behaved and only schedule a
> timer when they will have work to do, they may not schedule a timer
> at all after the data is saved, and so would have the data safe and
> just as long a standby time.
>
> >>>>>But that doesn't guarantee that solutions developed for PCs and laptops
> >>>>>will be optimal (or even usable) on cellphones. Sufficient difference
> >>>>
> >>>>Your cellphone is to all intents a laptop from ten years ago, it even has
> >>>>a similar display resolution and internet availability. The underlying
> >>>>difference between the two is solely form factor - the laptop had a
> >>>>better keyboard.
> >>>
> >>>There are similarities and differences. You have called out some of
> >>>the similarities. Differences include the more-aggressive hardware
> >>>power management on cellphones, the greater number and variety of
> >>>hardware accelerators on cellphones, battery capacity, and, as you say,
> >>>physical size. People currently use cellphones differently than they
> >>>do laptops or desktops. The usage might converge, but we will see.
> >>>There is as much reason to expect increasing specialization as there
> >>>is to expect increasing convergence.
> >>
> >>You are talking about Android as if it was a cell phone only thing,
> >>it's not. there are shipping tablets (and I believe netbooks, i.e.
> >>laptops) running andoid.
> >
> >I was talking about cellphones. But yes, Android (and thus suspend
> >blockers) are used for tablets as well as cellphones, thank you for
> >reminding me!
>
> the fact that it's used there means that you can't argue that it's
> difference because cell phones are so different (unless you are
> saying that Android is really not appropriate for those uses)
>
> On the other hand, lots of things are used in places where it is
> inappropriate, Windows CE is used on phones, tablets, etc but I
> think most people would say that the use of windows there isn't
> appropriate.
>
> David Lang
On Thu, Aug 12, 2010 at 1:12 AM, Paul E. McKenney
<[email protected]> wrote:
> On Wed, Aug 11, 2010 at 11:00:42PM +0300, Felipe Contreras wrote:
>> On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney
>> <[email protected]> wrote:
>> > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>> >> You may also wish to review the earlier parts of the discussion where it
>> >> was explicitly stated by several developers that they were using
>> >> "suspend" type modes as power states already and not using suspend
>> >> blockers. So it's being done, today on ARM and your statement is directly
>> >> contradicting the code. Modern ARM processors and x86 MID devices can
>> >> suspend and resume extremely fast (fast enough that the fact Linux x86
>> >> rewriting all the SMP alternatives on suspend/resume is a measurable
>> >> problem). If this same property doesn't end up on big PC boxes in time
>> >> then I'd be very surprised. At that point the openoffice with suspend
>> >> blockers or oracle with suspend blockers question becomes rather relevant.
>> >
>> > Here is the list of properties distinguishing idle from suspend:
>> >
>> > 1. Idle states are entered by a given CPU only there are no runnable
>> > tasks for that CPU. In contrast, opportunistic suspend can
>> > halt the entire system even when there are tasks that are ready,
>> > willing, and able to run. (But please note that this might not
>> > apply to real-time tasks.)
>>
>> But if there are no runnable tasks (which is the target), they behave the same.
>
> And if there are runnable tasks, then then don't behave the same.
Unless they have blocked suspend.
Anyway, Alan was picturing a hypothetical point in time when x86 can
suspend/resume as fast as ARM, and thus the question of whether or not
to enable suspend-blockers in a system that runs openoffice becomes
relevant. If applications have been fixed by that time to not wake the
system unnecessarily, as many of them have already been tanks to tools
like powertop, then suspend-blockers would not make that much of a
difference, therefore the effort required to implement
suspend-blockers properly on all applications in the system, including
openoffice might not be worth the gain.
> Apparently different people in this debate have different targets.
I remember clearly Android people explaining that dynamic PM is
orthogonal to suspend-blockers; if a suspend is blocked, you still
want dynamic PM to reach the lower power state. Therefore the target
of not having unneeded runnable tasks is shared by Android folks.
>> > 2. There can be a set of input events that do not bring the system
>> > out of suspend, but which would bring the system out of idle.
>> > Exactly which events are in this set depends both on hardware
>> > capabilities and on the platform/application policy. For example,
>> > on one of the Android-based smartphones, touchscreen input is
>> > ignored when the system is suspended, but is handled when idle.
>>
>> And in N900 touching the screen doesn't bring the device out of idle,
>> I guess because it's off.
>
> As long as touching the N900 screen doesn't bring the device out of
> suspend, its behavior is not a counterexample to #2 above.
You said "there can be a set of input events that do not bring the
system out of suspend, but which would bring the system out of idle".
There's no suspend (in the Android sense) in N900, only idle, and the
events that bring N900 out of idle can be mapped to the set of events
that bring Android out of suspend.
IOW. Alan wasn't talking about idle vs suspend on the same device, he
was talking about opportunistic suspend vs dynamic PM.
>> > 3. The system comes out of idle when a timer expires. In contrast,
>> > timers might or might not bring the system out of suspend,
>> > depending on both hardware capabilities and platform/application
>> > policy.
>>
>> Isn't this solved by range timers?
>
> Ahem. This is a list of differences between idle and suspend, not
> a list of problems to be solved. But to answer your question, if a
> timer does not bring a given device out of suspend, then a range timer
> is not likely to, either. Don't get me wrong, I do believe that range
> timers have an important part to play in the energy-efficiency arena,
> but I have not been convinced that they are any kind of silver bullet.
Certainly, but the context is the set of differences that would aid in
the decision of whether or not to go for suspend-blockers in a general
purpose system where openoffice would run.
>> > 4. Suspend generally forces devices to go into their low-power
>> > states immediately. In contrast, idle generally leaves unused
>> > devices at full power, relying on timers to shut down these
>> > devices. Idle thus has shorter average wakeup latencies, but
>> > worse energy efficiency.
>>
>> Only if you make these assumptions
>> 1) All the applications use suspend-blockers only when they absolutely must
>> 2) The user has given the right applications the right access
>
> You believe that these assumptions are unreasonable? Compared to the
> assumption that all applications are carefully written to conserve power?
> If so, on what grounds?
No, I think both (for opportunistic suspend and dynamic PM) are
completely reasonable. But think again; if you have the assumptions
met on both, then both work fine, if you don't meet them, then both
don't work correctly.
My point is that suspend-blockers don't magically reduce power usage,
just like dynamic PM, it depends on what user-space actually does. You
made it look as it *always* reached better energy efficiency.
> It seems to me that the same social-engineering approaches work in
> both cases.
Yes, but if dynamic PM works as advertised, you don't need
opportunistic suspend.
>> If not, you'll see much worst energy efficiency. So in theory maybe,
>> but in practice you can't say that.
>
> Really? What makes you say that?
For starters an application might be holding the wakelock more than it
should, also, an application might miss a timer due to not having PM
permissions to hold the lock, and thus might need an expensive
initialization when it runs again.
--
Felipe Contreras
On Sun, Aug 8, 2010 at 9:34 PM, Mark Brown
<[email protected]> wrote:
> On 8 Aug 2010, at 18:08, Felipe Contreras <[email protected]> wrote:
>
>> On Sun, Aug 8, 2010 at 7:08 PM, Matthew Garrett <[email protected]> wrote:
>>> It's clearly possible for a pathological Android application to destroy
>>> the power management policy. But to do that, the author would have to
>>> explicitly take a wakelock. That's difficult to do by accident.
>>
>> The writer can take a wakelock the whole time the application is
>> running (isn't that the typical case?), because perhaps the author
>> realizes that way the application works correctly, or he copy-pasted
>> it from somewhere else.
>
> That would be exceptionally unusual. A more common case is that the application will take a wakelock while performing some specific long running task which needs no user intervention such as downloading a file or displaying constantly update status that the user is not expected to respond to. There's no need for applications to take wakelocks while the user is directly interacting with them since the system will be kept awake as a result of the user interaction, the wakelocks are used to override the default suspend that occurs when the user is not interacting with the device.
Fair enough, but if that the case, if suspend blockers are to be used
in desktop software, everything would need extensive modifications
just to work. I remember somebody said that was not the case, I
thought it was because the lock could be held the whole time the
application is running.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney
<[email protected]> wrote:
> On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote:
>> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
>> <[email protected]> wrote:
>> > But wouldn't an office suite run as a power-oblivious application on an
>> > Android device? After all, office applications do not need to run when
>> > the screen is turned off, so these the applications do not need to use
>> > suspend blockers.
>>
>> Ideally the system would be suspended even when the screen is on. If
>> there are no "trusted" applications running at the same time, then
>> openoffice wouldn't load at all. Right?
>
> My understanding is that Android systems in fact do not suspend when
> the screen is on, and that most (perhaps all) other systems do not
> opportunistically suspend at all. There has been some speculation about
> what a hypothetical Android having a non-volatile display might do,
> but as far as I know, this is just speculation.
I have a desktop system in mind. If opportunistic suspend is only
triggered when the display is off, then it's no good for normal usage,
and therefore dynamic PC needs to get its act together... specially
for laptops.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 1:12 AM, Brian Swetland <[email protected]> wrote:
> On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras
> <[email protected]> wrote:
>> This is what I'm talking about when I say multi-tasking, Android
>> certainly doesn't have anything remotely like that:
>> http://www.youtube.com/watch?v=7emvUBpEkbU
>
> Home + pick app -> switch to the app in whatever state it was in.
If the app stops running, that's *fake* multi-tasking, and doesn't
match my experience; I can't remember the details, but I tested it on
a Nexus One, and the item I was looking at was gone, I had to scroll
again.
Also, I cannot go to last.fm on the browser, play some music, and do
other stuff at the same time, can I?
Anyway, what you do in Android is your problem. The point is that in
Linux we need good PM *with* multi-tasking (not really an argument
against opportunistic suspend, I think, but a clarification from Ted's
comment)
--
Felipe Contreras
On Wed, Aug 11, 2010 at 5:46 PM, Felipe Contreras
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 1:12 AM, Brian Swetland <[email protected]> wrote:
>> On Wed, Aug 11, 2010 at 3:03 PM, Felipe Contreras
>> <[email protected]> wrote:
>>> This is what I'm talking about when I say multi-tasking, Android
>>> certainly doesn't have anything remotely like that:
>>> http://www.youtube.com/watch?v=7emvUBpEkbU
>>
>> Home + pick app -> switch to the app in whatever state it was in.
>
> If the app stops running, that's *fake* multi-tasking, and doesn't
> match my experience; I can't remember the details, but I tested it on
> a Nexus One, and the item I was looking at was gone, I had to scroll
> again.
That'd be surprise. Last I checked I was able to launch 40-50 apps on
N1 before we even started getting low on memory and the system won't
kill apps off unless we completely bottom out on memory. It's
possible that some app might do the wrong thing when going to the
background and back to the foreground but that'd be an app bug.
> Also, I cannot go to last.fm on the browser, play some music, and do
> other stuff at the same time, can I?
I'm not sure off the top of my head if the browser will keep
music/flash playing on pages when it's not the foreground app, but you
can certainly run something like Pandora (or a number of other
streaming music apps) in the background and play streaming music while
you do other stuff. There's no reason the browser *couldn't* do this
as well.
> Anyway, what you do in Android is your problem. The point is that in
> Linux we need good PM *with* multi-tasking (not really an argument
> against opportunistic suspend, I think, but a clarification from Ted's
> comment)
Well I'm glad we agree that multitasking and PM are important.
Brian
On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney
> <[email protected]> wrote:
> > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote:
> >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
> >> <[email protected]> wrote:
> >> > But wouldn't an office suite run as a power-oblivious application on an
> >> > Android device? ?After all, office applications do not need to run when
> >> > the screen is turned off, so these the applications do not need to use
> >> > suspend blockers.
> >>
> >> Ideally the system would be suspended even when the screen is on. If
> >> there are no "trusted" applications running at the same time, then
> >> openoffice wouldn't load at all. Right?
> >
> > My understanding is that Android systems in fact do not suspend when
> > the screen is on, and that most (perhaps all) other systems do not
> > opportunistically suspend at all. ?There has been some speculation about
> > what a hypothetical Android having a non-volatile display might do,
> > but as far as I know, this is just speculation.
>
> I have a desktop system in mind. If opportunistic suspend is only
> triggered when the display is off, then it's no good for normal usage,
> and therefore dynamic PC needs to get its act together... specially
> for laptops.
If I understand you correctly, you are saying that both opportunistic
suspend and dynamic power control should be used together, with dynamic
power control being used for short non-busy periods (as in between
keystrokes) and opportunistic suspend being used for longer non-busy
periods (as in while grabbing a coffee). That combination of usage
sounds promising to me.
That said, I don't know that anyone has really sat down and thought
through how one might apply suspend blockers to a desktop system.
I suspect that there are several ways to go about it.
Thanx, Paul
On Thu, Aug 12, 2010 at 4:06 AM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote:
>> On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney
>> <[email protected]> wrote:
>> > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote:
>> >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
>> >> <[email protected]> wrote:
>> >> > But wouldn't an office suite run as a power-oblivious application on an
>> >> > Android device? After all, office applications do not need to run when
>> >> > the screen is turned off, so these the applications do not need to use
>> >> > suspend blockers.
>> >>
>> >> Ideally the system would be suspended even when the screen is on. If
>> >> there are no "trusted" applications running at the same time, then
>> >> openoffice wouldn't load at all. Right?
>> >
>> > My understanding is that Android systems in fact do not suspend when
>> > the screen is on, and that most (perhaps all) other systems do not
>> > opportunistically suspend at all. There has been some speculation about
>> > what a hypothetical Android having a non-volatile display might do,
>> > but as far as I know, this is just speculation.
>>
>> I have a desktop system in mind. If opportunistic suspend is only
>> triggered when the display is off, then it's no good for normal usage,
>> and therefore dynamic PC needs to get its act together... specially
>> for laptops.
>
> If I understand you correctly, you are saying that both opportunistic
> suspend and dynamic power control should be used together, with dynamic
> power control being used for short non-busy periods (as in between
> keystrokes) and opportunistic suspend being used for longer non-busy
> periods (as in while grabbing a coffee). That combination of usage
> sounds promising to me.
No. In the future x86 will be fixed, but for now let's imagine an ARM laptop.
> That said, I don't know that anyone has really sat down and thought
> through how one might apply suspend blockers to a desktop system.
> I suspect that there are several ways to go about it.
Think in terms of an ARM laptop. What good is opportunistic suspend if
it's not going to help when the laptop is being used?
--
Felipe Contreras
On Thu, Aug 12, 2010 at 04:25:21AM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 4:06 AM, Paul E. McKenney
> <[email protected]> wrote:
> > On Thu, Aug 12, 2010 at 03:28:00AM +0300, Felipe Contreras wrote:
> >> On Thu, Aug 12, 2010 at 1:28 AM, Paul E. McKenney
> >> <[email protected]> wrote:
> >> > On Wed, Aug 11, 2010 at 10:18:51PM +0300, Felipe Contreras wrote:
> >> >> On Mon, Aug 9, 2010 at 9:16 PM, Paul E. McKenney
> >> >> <[email protected]> wrote:
> >> >> > But wouldn't an office suite run as a power-oblivious application on an
> >> >> > Android device? ?After all, office applications do not need to run when
> >> >> > the screen is turned off, so these the applications do not need to use
> >> >> > suspend blockers.
> >> >>
> >> >> Ideally the system would be suspended even when the screen is on. If
> >> >> there are no "trusted" applications running at the same time, then
> >> >> openoffice wouldn't load at all. Right?
> >> >
> >> > My understanding is that Android systems in fact do not suspend when
> >> > the screen is on, and that most (perhaps all) other systems do not
> >> > opportunistically suspend at all. ?There has been some speculation about
> >> > what a hypothetical Android having a non-volatile display might do,
> >> > but as far as I know, this is just speculation.
> >>
> >> I have a desktop system in mind. If opportunistic suspend is only
> >> triggered when the display is off, then it's no good for normal usage,
> >> and therefore dynamic PC needs to get its act together... specially
> >> for laptops.
> >
> > If I understand you correctly, you are saying that both opportunistic
> > suspend and dynamic power control should be used together, with dynamic
> > power control being used for short non-busy periods (as in between
> > keystrokes) and opportunistic suspend being used for longer non-busy
> > periods (as in while grabbing a coffee). ?That combination of usage
> > sounds promising to me.
>
> No. In the future x86 will be fixed, but for now let's imagine an ARM laptop.
Hmmm... OK...
> > That said, I don't know that anyone has really sat down and thought
> > through how one might apply suspend blockers to a desktop system.
> > I suspect that there are several ways to go about it.
>
> Think in terms of an ARM laptop. What good is opportunistic suspend if
> it's not going to help when the laptop is being used?
For when the laptop is not being used, presumably.
Thanx, Paul
On Thu, Aug 12, 2010 at 6:44 AM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 04:25:21AM +0300, Felipe Contreras wrote:
>> Think in terms of an ARM laptop. What good is opportunistic suspend if
>> it's not going to help when the laptop is being used?
>
> For when the laptop is not being used, presumably.
Right, but if you have to optimize for dynamic PM anyway for normal
usage, how much would you gain by opportunistic suspend?
As it has been explained before, there's a point of diminishing returns:
http://article.gmane.org/gmane.linux.kernel/995525
http://article.gmane.org/gmane.linux.ports.arm.omap/37982
Now, how much would dynamic PM have progressed by the time we start
thinking on opportunistic suspend on laptops (ARM, or fixed PM), 10
seconds idle? 1 minute idle? Would it make sense to rewrite *all*
user-space in order to archive that little extra performance, *or*
would it make more sense to keep investing on dynamic PM which we have
to do anyway?
All this has already been explained.
BTW, the gain is even less if you consider that laptops already
automatically go to suspend after a while, so the gains of
opportunistic suspend would have to be measured only for a small
period of time (like 30 min or so).
--
Felipe Contreras
Felipe,
One thing I'm not clear on --- what's your goal? Is your goal to keep suspend-blockers out of the kernel? Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? Is it to push some other agenda? Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel?
You seem to be arguing quite passionately, but I'm not sure what you're trying to do.
-- Ted
On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <[email protected]> wrote:
> One thing I'm not clear on --- what's your goal? Is your goal to keep suspend-blockers out of the kernel? Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? Is it to push some other agenda? Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel?
My goal is to shine light. I've heard many invalid arguments in favor
of suspend blockers, I want to shut them down.
In my mind it's crystal clear that independently of what opportunistic
suspend is supposed to be fixing, the fact of the matter is that it's
not a silver bullet as it's claimed to be.
So far, nobody has refuted these:
1) opportunistic suspend needs a good behaved user-space to work properly
2) if suspend blockers are enabled in a system, *all* user-space must
implement them to work correctly
3) implementing suspend blockers in user-space is not a straight-forward task
4) there's a point where sleeping (not doing work) has diminished returns
So, as the length of this thread has shown, the benefits of
opportunistic suspend are *dubious* at best, and more likely not worth
the changes needed in user-space which eventually will get pretty
close to what suspend blockers can achieve even in ideal circumstances
by just doing dynamic PM.
--
Felipe Contreras
On Thu, 12 Aug 2010, Felipe Contreras wrote:
> My goal is to shine light. I've heard many invalid arguments in favor
> of suspend blockers, I want to shut them down.
>
> In my mind it's crystal clear that independently of what opportunistic
> suspend is supposed to be fixing, the fact of the matter is that it's
> not a silver bullet as it's claimed to be.
>
> So far, nobody has refuted these:
> 1) opportunistic suspend needs a good behaved user-space to work properly
That seems entirely reasonable, since opportunistic suspend is
essentially a userspace facility. Its in-kernel component is extremely
small (and is already in mainline).
> 2) if suspend blockers are enabled in a system, *all* user-space must
> implement them to work correctly
That isn't clear at all. Certainly they must be implemented correctly
in some parts of userspace. But other parts can simply be denied
permission to use them.
> 3) implementing suspend blockers in user-space is not a straight-forward task
Perhaps so. Lots of things in userspace aren't straight-forward --
GUIs, for example. So what? That's not a proof they shouldn't be
used.
> 4) there's a point where sleeping (not doing work) has diminished returns
Agreed. It is platform dependent. The Google people seem to believe
strongly they have not yet reached that point on their platforms.
> So, as the length of this thread has shown, the benefits of
> opportunistic suspend are *dubious* at best, and more likely not worth
> the changes needed in user-space which eventually will get pretty
> close to what suspend blockers can achieve even in ideal circumstances
> by just doing dynamic PM.
You're ignoring the fact that Android has _already_ made the necessary
userspace changes. Now you're going to ask them to change back,
offering as motivation the loss of a real (albeit "dubious")
power-saving advantage? Why should they accept your offer?
Alan Stern
On Thu, Aug 12, 2010 at 2:40 PM, Alan Stern <[email protected]> wrote:
> On Thu, 12 Aug 2010, Felipe Contreras wrote:
>
>> My goal is to shine light. I've heard many invalid arguments in favor
>> of suspend blockers, I want to shut them down.
>>
>> In my mind it's crystal clear that independently of what opportunistic
>> suspend is supposed to be fixing, the fact of the matter is that it's
>> not a silver bullet as it's claimed to be.
>>
>> So far, nobody has refuted these:
[...]
>> 2) if suspend blockers are enabled in a system, *all* user-space must
>> implement them to work correctly
>
> That isn't clear at all. Certainly they must be implemented correctly
> in some parts of userspace. But other parts can simply be denied
> permission to use them.
Yes, but all user-space needs to be considered. There certainly will
be cases when people think a certain package doesn't need them, but it
turns out they did. Firefox? Nah... oh, wait a second, I want my
downloads to finish. Do you think there will be any linux desktop
distro willing to attempt that?
>> 3) implementing suspend blockers in user-space is not a straight-forward task
>
> Perhaps so. Lots of things in userspace aren't straight-forward --
> GUIs, for example. So what? That's not a proof they shouldn't be
> used.
Certainly not, but it means when measuring against plain dynamic PM,
opportunistic suspend is less attractive.
>> 4) there's a point where sleeping (not doing work) has diminished returns
>
> Agreed. It is platform dependent. The Google people seem to believe
> strongly they have not yet reached that point on their platforms.
Yes, and Nokia/Intel people believe they are close on their platforms.
Surely, at some point Android will reach that point too.
>> So, as the length of this thread has shown, the benefits of
>> opportunistic suspend are *dubious* at best, and more likely not worth
>> the changes needed in user-space which eventually will get pretty
>> close to what suspend blockers can achieve even in ideal circumstances
>> by just doing dynamic PM.
>
> You're ignoring the fact that Android has _already_ made the necessary
> userspace changes. Now you're going to ask them to change back,
> offering as motivation the loss of a real (albeit "dubious")
> power-saving advantage? Why should they accept your offer?
Android people have been selling the idea that suspend blockers are
not only for Android, but other platforms can benefit from them too. I
am arguing in that context. Hopefully you agree that that claim is
dubious at best.
Now, switching to Android... I'm sure if Android guys say their
user-space is far from the dynamic PM sweet-spot, then that's the
case. Surely, at some point they will reach it, so that they can
minimize power usage even when the device is actively used (it has
been explained that opportunistic suspend is not activated when screen
is on), maybe it will take one year, maybe two. Will they keep
opportunistic suspend around for those marginal gains? Maybe.
The question is why are we adding a user-space API that:
1) no user-space beside Android has expresses interest in implementing
2) is dubious whether the benefits are worth the pain for non-Android
user-space
3) will become less and less attractive as dynamic PM gets closer to
the sweet-spot, and then surpass it
4) Android can keep in a separate tree until it's clear in the linux
community that it's useful (if it ever happens)
--
Felipe Contreras
On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
>
> The question is why are we adding a user-space API that:
> 1) no user-space beside Android has expresses interest in implementing
> 2) is dubious whether the benefits are worth the pain for non-Android
> user-space
> 3) will become less and less attractive as dynamic PM gets closer to
> the sweet-spot, and then surpass it
> 4) Android can keep in a separate tree until it's clear in the linux
> community that it's useful (if it ever happens)
So, Felipe,
Do you believe you speak for all of LKML?
Are you willing to tell ZDNet and the Slashdot fanboys that it's OK
for Suspend blockers to live in a separate tree, and it's not a case
of OMG! Google is forking the kernel?
If you could speak out a passionately on those forums as you have
here, that would be great.
- Ted
On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
> So far, nobody has refuted these:
> 1) opportunistic suspend needs a good behaved user-space to work properly
> 2) if suspend blockers are enabled in a system, *all* user-space must
> implement them to work correctly
For this note that there's a fairly strong expectation that even in a
phone type environment a sane userspace implementation will involve a
very large portion of userspace just totally ignoring suspend blockers.
This means that while it is true that userspace as a whole must have
support for suspend blockers the changes required are substantially less
invasive than you appear to expecting.
On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 1:12 AM, Paul E. McKenney
> <[email protected]> wrote:
> > On Wed, Aug 11, 2010 at 11:00:42PM +0300, Felipe Contreras wrote:
> >> On Wed, Aug 11, 2010 at 3:42 AM, Paul E. McKenney
> >> <[email protected]> wrote:
> >> > On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
> >> >> You may also wish to review the earlier parts of the discussion where it
> >> >> was explicitly stated by several developers that they were using
> >> >> "suspend" type modes as power states already and not using suspend
> >> >> blockers. So it's being done, today on ARM and your statement is directly
> >> >> contradicting the code. Modern ARM processors and x86 MID devices can
> >> >> suspend and resume extremely fast (fast enough that the fact Linux x86
> >> >> rewriting all the SMP alternatives on suspend/resume is a measurable
> >> >> problem). If this same property doesn't end up on big PC boxes in time
> >> >> then I'd be very surprised. At that point the openoffice with suspend
> >> >> blockers or oracle with suspend blockers question becomes rather relevant.
> >> >
> >> > Here is the list of properties distinguishing idle from suspend:
> >> >
> >> > 1. ? ? ?Idle states are entered by a given CPU only there are no runnable
> >> > ? ? ? ?tasks for that CPU. ?In contrast, opportunistic suspend can
> >> > ? ? ? ?halt the entire system even when there are tasks that are ready,
> >> > ? ? ? ?willing, and able to run. ?(But please note that this might not
> >> > ? ? ? ?apply to real-time tasks.)
> >>
> >> But if there are no runnable tasks (which is the target), they behave the same.
> >
> > And if there are runnable tasks, then then don't behave the same.
>
> Unless they have blocked suspend.
You are quite correct. I should have said something like "But if there
are runnable tasks, none of which is holding a suspend blocker, then
they don't behave the same."
> Anyway, Alan was picturing a hypothetical point in time when x86 can
> suspend/resume as fast as ARM, and thus the question of whether or not
> to enable suspend-blockers in a system that runs openoffice becomes
> relevant. If applications have been fixed by that time to not wake the
> system unnecessarily, as many of them have already been tanks to tools
> like powertop, then suspend-blockers would not make that much of a
> difference, therefore the effort required to implement
> suspend-blockers properly on all applications in the system, including
> openoffice might not be worth the gain.
One more time, this time with feeling. ;-)
Only PM-driving applications need concern themselves with suspend
blockers, and experience thus far indicates that PM-driving
applications are a very small fraction of the total.
> > Apparently different people in this debate have different targets.
>
> I remember clearly Android people explaining that dynamic PM is
> orthogonal to suspend-blockers; if a suspend is blocked, you still
> want dynamic PM to reach the lower power state. Therefore the target
> of not having unneeded runnable tasks is shared by Android folks.
And I have not seen anyone argue that suspend blockers are a replacement
for dynamic power management. Many people instead seem to be advocating
using them both -- dynamic power management for when at least one
PM-driving application or kernel driver is keeping the system awake, and
suspend blockers for when only power-oblivious applications are running.
In contrast, you are advocating dynamic power management to the exclusion
of other mechanisms.
> >> > 2. ? ? ?There can be a set of input events that do not bring the system
> >> > ? ? ? ?out of suspend, but which would bring the system out of idle.
> >> > ? ? ? ?Exactly which events are in this set depends both on hardware
> >> > ? ? ? ?capabilities and on the platform/application policy. ?For example,
> >> > ? ? ? ?on one of the Android-based smartphones, touchscreen input is
> >> > ? ? ? ?ignored when the system is suspended, but is handled when idle.
> >>
> >> And in N900 touching the screen doesn't bring the device out of idle,
> >> I guess because it's off.
> >
> > As long as touching the N900 screen doesn't bring the device out of
> > suspend, its behavior is not a counterexample to #2 above.
>
> You said "there can be a set of input events that do not bring the
> system out of suspend, but which would bring the system out of idle".
> There's no suspend (in the Android sense) in N900, only idle, and the
> events that bring N900 out of idle can be mapped to the set of events
> that bring Android out of suspend.
We do seem to be in violent agreement.
> IOW. Alan wasn't talking about idle vs suspend on the same device, he
> was talking about opportunistic suspend vs dynamic PM.
The most convincing comparisons will be of suspend vs. idle on the
same device. If multiple devices are involved, then the most convincing
experiments would compare suspend vs. idle separately on each device.
So, are you sure that you are correctly interpreting Alan's words?
> >> > 3. ? ? ?The system comes out of idle when a timer expires. ?In contrast,
> >> > ? ? ? ?timers might or might not bring the system out of suspend,
> >> > ? ? ? ?depending on both hardware capabilities and platform/application
> >> > ? ? ? ?policy.
> >>
> >> Isn't this solved by range timers?
> >
> > Ahem. ?This is a list of differences between idle and suspend, not
> > a list of problems to be solved. ?But to answer your question, if a
> > timer does not bring a given device out of suspend, then a range timer
> > is not likely to, either. ?Don't get me wrong, I do believe that range
> > timers have an important part to play in the energy-efficiency arena,
> > but I have not been convinced that they are any kind of silver bullet.
>
> Certainly, but the context is the set of differences that would aid in
> the decision of whether or not to go for suspend-blockers in a general
> purpose system where openoffice would run.
Again, I am in no way arguing for suspend blockers to the exclusion of
other approaches. Heck, I am mostly just trying to get a clear statement
of the problem. In contrast, you do seem to be advocating for dynamic
power management to the exclusion of other approaches.
> >> > 4. ? ? ?Suspend generally forces devices to go into their low-power
> >> > ? ? ? ?states immediately. ?In contrast, idle generally leaves unused
> >> > ? ? ? ?devices at full power, relying on timers to shut down these
> >> > ? ? ? ?devices. ?Idle thus has shorter average wakeup latencies, but
> >> > ? ? ? ?worse energy efficiency.
> >>
> >> Only if you make these assumptions
> >> ?1) All the applications use suspend-blockers only when they absolutely must
> >> ?2) The user has given the right applications the right access
> >
> > You believe that these assumptions are unreasonable? ?Compared to the
> > assumption that all applications are carefully written to conserve power?
> > If so, on what grounds?
>
> No, I think both (for opportunistic suspend and dynamic PM) are
> completely reasonable. But think again; if you have the assumptions
> met on both, then both work fine, if you don't meet them, then both
> don't work correctly.
That is true of any artifact, software or otherwise: if you don't meet the
assumptions inherent in its design and construction, the artifact might
fail. Of course, you argument also applies to dynamic power management:
and in fact it takes just one power-oblivious application to drain your
battery -- especially if that application goes into an infinite loop.
And if that application goes into an infinite loop only under some
unusual set of conditions, it might have passed your test suite with
flying colors, so that you might even have given it a power-management
gold star, right?
And yes, you can get the same effect with an infinite loop in a
PM-driving application that happens to be holding suspend blockers
at the time. However, in the suspend-blocker case, one need only
inspect that code that holds suspend blockers. In the dynamic
power management case, one must inspect -all- the code. There is
a very real difference between those two tasks.
So are you sure that dynamic power management will turn out to be
the right tool for every job out there? If so, on what grounds?
> My point is that suspend-blockers don't magically reduce power usage,
> just like dynamic PM, it depends on what user-space actually does. You
> made it look as it *always* reached better energy efficiency.
I do? Really??? Exactly what did I say to give you that impression?
I am not saying that suspend blockers are the right tool for every
power management job, instead, I am asking whether there are some power
management jobs for which it is the best tool.
> > It seems to me that the same social-engineering approaches work in
> > both cases.
>
> Yes, but if dynamic PM works as advertised, you don't need
> opportunistic suspend.
For dynamic power management to totally eliminate the need for something
like suspend blockers, you are having to make some brave assumptions.
Yes, dynamic power management is quite useful, but there is a big
difference between something being useful and something doing everything
for everyone. You have not yet convinced me that dynamic power management
will make it to the "doing everything for everyone" stage.
> >> If not, you'll see much worst energy efficiency. So in theory maybe,
> >> but in practice you can't say that.
> >
> > Really? ?What makes you say that?
>
> For starters an application might be holding the wakelock more than it
> should, also, an application might miss a timer due to not having PM
> permissions to hold the lock, and thus might need an expensive
> initialization when it runs again.
Just as an application might run continuously without blocking, which
would defeat the dynamic power management scheme that have thus far been
put forward. And just as an application might miss a timer due to
dynamic power management having decided that it didn't need that timer
to fire at the desired time.
Thanx, Paul
On Thu, Aug 12, 2010 at 3:52 PM, Ted Ts'o <[email protected]> wrote:
> On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
>>
>> The question is why are we adding a user-space API that:
>> 1) no user-space beside Android has expresses interest in implementing
>> 2) is dubious whether the benefits are worth the pain for non-Android
>> user-space
>> 3) will become less and less attractive as dynamic PM gets closer to
>> the sweet-spot, and then surpass it
>> 4) Android can keep in a separate tree until it's clear in the linux
>> community that it's useful (if it ever happens)
>
> Do you believe you speak for all of LKML?
No. I'm speaking for myself, and that includes a lot of what people on
LKML have already said.
> Are you willing to tell ZDNet and the Slashdot fanboys that it's OK
> for Suspend blockers to live in a separate tree, and it's not a case
> of OMG! Google is forking the kernel?
All the Android community had to do is push the drivers *without*
suspend blockers, then the Android kernel wouldn't be so different and
thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
are already in the kernel, so there's no excuse not to merge the
drivers.
Then people would stop blaming Google for forking the kernel.
Nobody from the "media" cares about suspend blockers; they are a small
patch which cannot be considered a fork, more like a hack, like many
other platforms have.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 5:09 PM, Mark Brown
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
>
>> So far, nobody has refuted these:
>> 1) opportunistic suspend needs a good behaved user-space to work properly
>> 2) if suspend blockers are enabled in a system, *all* user-space must
>> implement them to work correctly
>
> For this note that there's a fairly strong expectation that even in a
> phone type environment a sane userspace implementation will involve a
> very large portion of userspace just totally ignoring suspend blockers.
> This means that while it is true that userspace as a whole must have
> support for suspend blockers the changes required are substantially less
> invasive than you appear to expecting.
Correct, but still a considerable amount of changes would need to be
done, which _nobody_ has expressed any intention to do.
Besides, IMO a good mobile platform would share as much as possible
with desktop software. Say, the improvements Nokia has endorsed on the
Telepathy IM framework can only help the people already using it on
the desktop.
However, personally, if I ever have to do './configure
--enable-suspend-blockers', I would think that something that just
doesn't belong has creped by to user-space. I don't see why there
should something particularly different between mobile phones and
laptops, and I think this has been already expressed over, and over.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 9:57 AM, Felipe Contreras
<[email protected]> wrote:
>
> Correct, but still a considerable amount of changes would need to be
> done, which _nobody_ has expressed any intention to do.
>
> Besides, IMO a good mobile platform would share as much as possible
> with desktop software. Say, the improvements Nokia has endorsed on the
> Telepathy IM framework can only help the people already using it on
> the desktop.
>
> However, personally, if I ever have to do './configure
> --enable-suspend-blockers', I would think that something that just
> doesn't belong has creped by to user-space. I don't see why there
> should something particularly different between mobile phones and
> laptops, and I think this has been already expressed over, and over.
So, because you feel that phones should be little laptops you oppose
providing (optional!) support for environments that take a different
view to that?
I'll echo Ted's question -- is this the opinion of the kernel
community at large? If so, there's not much point in continuing to
have discussions around suspend blockers.
I think that we're still a ways away from a world where we can treat
mobile devices the same as laptops and get reasonable user
experiences. I think it's unfortunate if the attitude here is "wait
and someday it won't matter", especially because I'm skeptical that
we're likely to hit that "someday" any time soon.
Brian
On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 1:47 PM, Theodore Tso <[email protected]> wrote:
> > One thing I'm not clear on --- what's your goal? ? Is your goal to keep suspend-blockers out of the kernel? ? Is it to try to convince the android team suspend-blockers are a bad idea and to change Android to not use them? ?Is it to push some other agenda? ?Is it to discourage the Android team from trying to waste more time trying to get suspend-blockers (or equivalent functionality) from being added into the kernel?
>
> My goal is to shine light. I've heard many invalid arguments in favor
> of suspend blockers, I want to shut them down.
>
> In my mind it's crystal clear that independently of what opportunistic
> suspend is supposed to be fixing, the fact of the matter is that it's
> not a silver bullet as it's claimed to be.
The question is not whether suspend blockers are a silver bullet (in my
opinion there are no silver bullets), but rather whether or not suspend
blockers are useful.
> So far, nobody has refuted these:
> 1) opportunistic suspend needs a good behaved user-space to work properly
As does dynamic power management.
> 2) if suspend blockers are enabled in a system, *all* user-space must
> implement them to work correctly
Really? From what I can see, only PM-driving applications need to use
suspend blockers.
> 3) implementing suspend blockers in user-space is not a straight-forward task
Fortunately, experience thus far has shown that only a small fraction of
applications need to use suspend blockers. (Or perhaps you are instead
saying that the implementation of the suspend-blocker infrastructure
itself is not straightforward? It is not clear from your words.)
> 4) there's a point where sleeping (not doing work) has diminished returns
This one I agree with.
> So, as the length of this thread has shown, the benefits of
> opportunistic suspend are *dubious* at best, and more likely not worth
> the changes needed in user-space which eventually will get pretty
> close to what suspend blockers can achieve even in ideal circumstances
> by just doing dynamic PM.
The length of this thread (and the ones preceding it) is mostly due to
people talking past each other. For example, the Android folks seem to
believe that it is important that relatively unskilled people be able
to write simple apps, and that the system nevertheless be able to run
these apps in a relatively energy efficient manner. Your proposals do
not address this issue. This might be because you are not aware of
this desire, because you are not aware of the computing history that
argues in favor of this requirement, or because you simply don't like
this requirement. Whatever the reason, until you face this requirement
head on, either addressing it or proving that it need not be addressed,
you will continue to be talking past the Android folks.
Thanx, Paul
On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
>> Anyway, Alan was picturing a hypothetical point in time when x86 can
>> suspend/resume as fast as ARM, and thus the question of whether or not
>> to enable suspend-blockers in a system that runs openoffice becomes
>> relevant. If applications have been fixed by that time to not wake the
>> system unnecessarily, as many of them have already been tanks to tools
>> like powertop, then suspend-blockers would not make that much of a
>> difference, therefore the effort required to implement
>> suspend-blockers properly on all applications in the system, including
>> openoffice might not be worth the gain.
>
> One more time, this time with feeling. ;-)
>
> Only PM-driving applications need concern themselves with suspend
> blockers, and experience thus far indicates that PM-driving
> applications are a very small fraction of the total.
There's no experience on this. Have you tried to run a small debian
system with suspend blockers enabled? I can image at least all cron
daemons need modifications, probably dbus, links, lftp, wget, rsync
and a bunch of applications that download data too.
It's easy to speculate one way or the other, but the fact of the
matter is that we don't really know how many changes are needed in
order to have a functional system that actually benefits from suspend
blockers.
What we know is that if an application is not analyzed to see if it
needs suspend blockers, and implement them if needed, it might get
broken.
>> > Apparently different people in this debate have different targets.
>>
>> I remember clearly Android people explaining that dynamic PM is
>> orthogonal to suspend-blockers; if a suspend is blocked, you still
>> want dynamic PM to reach the lower power state. Therefore the target
>> of not having unneeded runnable tasks is shared by Android folks.
>
> And I have not seen anyone argue that suspend blockers are a replacement
> for dynamic power management.
That's exactly what I'm saying: they are orthogonal.
> In contrast, you are advocating dynamic power management to the exclusion
> of other mechanisms.
* if dynamic PM was perfect, spend-blockers would *not* be not needed
* if suspend-blockers were perfect, dynamic *will* still be needed
All I said in that sentence you are replying is that dynamic PM will
improve; it's a shared goal of everyone.
>> IOW. Alan wasn't talking about idle vs suspend on the same device, he
>> was talking about opportunistic suspend vs dynamic PM.
>
> The most convincing comparisons will be of suspend vs. idle on the
> same device. If multiple devices are involved, then the most convincing
> experiments would compare suspend vs. idle separately on each device.
>
> So, are you sure that you are correctly interpreting Alan's words?
The point you are trying to highlight is to which events the system
reacts, that has nothing to do with dynamic PM vs opportunistic
suspend.
> Again, I am in no way arguing for suspend blockers to the exclusion of
> other approaches. Heck, I am mostly just trying to get a clear statement
> of the problem. In contrast, you do seem to be advocating for dynamic
> power management to the exclusion of other approaches.
What you are doing is copy pasting a definition of what is
opportunistic suspend and making it pass as an advantage.
This particular point (3.) is not an advantage, over dynamic PM, it's
just a difference.
>> No, I think both (for opportunistic suspend and dynamic PM) are
>> completely reasonable. But think again; if you have the assumptions
>> met on both, then both work fine, if you don't meet them, then both
>> don't work correctly.
>
> That is true of any artifact, software or otherwise: if you don't meet the
> assumptions inherent in its design and construction, the artifact might
> fail.
[...]
> There is
> a very real difference between those two tasks.
I've cut most of your explanation. If I understand correctly what you
are saying is that suspend blockers are harder to get wrong. I agree,
but my point against 4. remains the same: suspend-blockers don't
automatically get you more efficient power usage.
> So are you sure that dynamic power management will turn out to be
> the right tool for every job out there? If so, on what grounds?
I don't understand this question. Dynamic PM is needed regardless. We
are discussing your point 4 where you say suspend blockers inevitably
lead to more efficient power usage (I say not necessarily).
>> My point is that suspend-blockers don't magically reduce power usage,
>> just like dynamic PM, it depends on what user-space actually does. You
>> made it look as it *always* reached better energy efficiency.
>
> I do? Really??? Exactly what did I say to give you that impression?
Here's your point 4 again:
> >> > 4. Suspend generally forces devices to go into their low-power
> >> > states immediately. In contrast, idle generally leaves unused
> >> > devices at full power, relying on timers to shut down these
> >> > devices. Idle thus has shorter average wakeup latencies, but
> >> > worse energy efficiency.
Remove "but worse energy efficiency" and I think that point would be
correct, albeit it's not really an argument in favor of opportunistic
suspend.
>> > It seems to me that the same social-engineering approaches work in
>> > both cases.
>>
>> Yes, but if dynamic PM works as advertised, you don't need
>> opportunistic suspend.
>
> For dynamic power management to totally eliminate the need for something
> like suspend blockers, you are having to make some brave assumptions.
> Yes, dynamic power management is quite useful, but there is a big
> difference between something being useful and something doing everything
> for everyone. You have not yet convinced me that dynamic power management
> will make it to the "doing everything for everyone" stage.
As it has been explained before, there's a sweet-spot of idleness:
http://article.gmane.org/gmane.linux.kernel/995525
http://article.gmane.org/gmane.linux.ports.arm.omap/37982
Do you agree that there's such a thing, and if so, do you agree that
the benefits of opportunistic suspend are much less once that point is
reached?
>> >> If not, you'll see much worst energy efficiency. So in theory maybe,
>> >> but in practice you can't say that.
>> >
>> > Really? What makes you say that?
>>
>> For starters an application might be holding the wakelock more than it
>> should, also, an application might miss a timer due to not having PM
>> permissions to hold the lock, and thus might need an expensive
>> initialization when it runs again.
>
> Just as an application might run continuously without blocking, which
> would defeat the dynamic power management scheme that have thus far been
> put forward. And just as an application might miss a timer due to
> dynamic power management having decided that it didn't need that timer
> to fire at the desired time.
You are making this discussion entropic, concentrate on what I said:
>>>> If not, you'll see much worst energy efficiency. So in theory maybe,
>>>> but in practice you can't say that.
I just proved to you that in certain cases opportunistic suspend might
actually hurt. Thus you should accept my premise that you can't say
that in practice opportunistic suspend _always_ leads to better
results, because that's not the case.
And in order to try to avoid going back to the same points:
1) yes, there are advantages of opportunistic suspend
2) yes, there are cases where it works as it should
3) no, it's not a silver bullet that will inevitably improve power usage
4) no, we can't say anything about what opportunistic suspend means in practice
--
Felipe Contreras
On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote:
> All the Android community had to do is push the drivers *without*
> suspend blockers, then the Android kernel wouldn't be so different and
> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
> are already in the kernel, so there's no excuse not to merge the
> drivers.
What's there is not good enough, because it's missing the statistics
and reporting so that badly behaved kernel and userspace drivers that
take wakelocks can be found.
I have a similar problem with the whole pm_qos subsystem, as I've said
earlier. If some badly behaved application claims to want 0us
wireless latency, and keeps the radio on all the time, there is no way
for me to find out which is the badly behaved application --- even
though I'm the owner of the laptop, and at the end of the day *I*
should be able to say, no, battery lifetime is more important than
what the application might think is its "minimum wireless latency".
Not only can I not override the application, I can't even find out
which application is at fault! ***FAIL***
In some ways, this is exactly the same problem as the "which badly
Maemo application is causing my causing my N770 to have its battery
laptop drop in half?".
- Ted
On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
> <[email protected]> wrote:
[ . . . ] (For now, anyway. I might respond to the rest later.)
> >> My point is that suspend-blockers don't magically reduce power usage,
> >> just like dynamic PM, it depends on what user-space actually does. You
> >> made it look as it *always* reached better energy efficiency.
> >
> > I do? ?Really??? ?Exactly what did I say to give you that impression?
>
> Here's your point 4 again:
>
> > >> > 4. Suspend generally forces devices to go into their low-power
> > >> > states immediately. In contrast, idle generally leaves unused
> > >> > devices at full power, relying on timers to shut down these
> > >> > devices. Idle thus has shorter average wakeup latencies, but
> > >> > worse energy efficiency.
>
> Remove "but worse energy efficiency" and I think that point would be
> correct,
Now this is much more like it!!! Thank you!!!
You are quite correct, my last sentence does in fact assume that suspend
will always have lower power consumption than does the deepest idle state.
This of course sentence must be fixed. How about the following, which
makes this assumption explicit, and adds words ("often", "might") that
indicate that one's mileage might vary?
4. Suspend generally forces devices to go into their
low-power states immediately. In contrast, idle generally
leaves unused devices at full power, relying on timers
to shut down these devices. Idle thus often has shorter
average wakeup latencies, but on systems where suspend
can use deeper sleep states than can idle, idle might
have worse energy efficiency.
> albeit it's not really an argument in favor of opportunistic
> suspend.
It never was intended to be an argument of any kind. It was instead
supposed to help clarify the difference between idle and suspend, in
response to people stating that there is no difference between suspend
and idle. If my mistake in the wording of the last sentence made you
think otherwise, please accept my apologies.
[ . . . ] (For now, anyway. I might respond to the rest later.)
Thanx, Paul
Hi Brian,
On Thu, Aug 12, 2010 at 8:33 PM, Brian Swetland <[email protected]> wrote:
> On Thu, Aug 12, 2010 at 9:57 AM, Felipe Contreras
> <[email protected]> wrote:
>>
>> Correct, but still a considerable amount of changes would need to be
>> done, which _nobody_ has expressed any intention to do.
>>
>> Besides, IMO a good mobile platform would share as much as possible
>> with desktop software. Say, the improvements Nokia has endorsed on the
>> Telepathy IM framework can only help the people already using it on
>> the desktop.
>>
>> However, personally, if I ever have to do './configure
>> --enable-suspend-blockers', I would think that something that just
>> doesn't belong has creped by to user-space. I don't see why there
>> should something particularly different between mobile phones and
>> laptops, and I think this has been already expressed over, and over.
>
> So, because you feel that phones should be little laptops you oppose
> providing (optional!) support for environments that take a different
> view to that?
Look. I'll share with you a little experience.
For years I've been working on a piece of software to access
Microsoft's WLM IM service on linux. I have high quality standards for
my software, so I optimized algorithms and bandwith, I used valgrind
to find memory leaks, OProfile for performance bottlenecks, and so on.
All this on a laptop.
When I ported this code to the N900 it just worked, not more-or-less;
perfectly. I could stay online the whole day without the battery
running out, and I didn't have to make *any* change.
Then at some point people started complaining about battery usage, but
lo and behold, on the desktop people started reporting too much
bandwith/cpu usage as well. I tried on my laptop, and was able to
reproduce, and fix (bug related to daylight savings time).
For years people have been trying to unify certain KDE/GNOME code, and
freedesktop.org was born. Now the same technologies are used by Nokia
on Maemo, and now MeeGo (DBus, Telepathy, GStreamer, tracker, etc.),
so the optimizations done for mobile benefit everyone; desktop power
usage also improves.
So, yeah, I think the fact that my laptop and phone share the same
software is great, and that improvements in one benefit the other.
> I think that we're still a ways away from a world where we can treat
> mobile devices the same as laptops and get reasonable user
> experiences.
Why do you keep ignoring the N900? It has a lot of components that
come directly from the linux ecosystem and people are having more than
reasonable experiences (some are ecstatic).
> I think it's unfortunate if the attitude here is "wait
> and someday it won't matter", especially because I'm skeptical that
> we're likely to hit that "someday" any time soon.
Nobody is waiting for anything. There's hard work all over the place
to improve power usage.
If you think suspend blockers are useful for you, great, use them. I
just don't see why they should be merged if nobody is going to use
them but you. But maybe you are right, and maybe dynamic PM alone
never reaches the same levers of performance, then people would ask
for it to be merged, and it will. No biggie.
In the meantime, it would be wise to remember that this is not
Nokia/Intel vs Google. Nokia has invested a great deal in dynamic PM,
and those changes have benefited Android products directly (I even
remember somebody from Google directly thanking Nokia for that), and
that will continue. So we are on the same team.
And finally, if they don't get merged, I hope you don't see that as a
loss. At the very least I think you got a lot of review comments from
the most qualified experts in the world _free of charge_, and as a
result the code should be more robust.
Cheers.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 9:21 PM, Ted Ts'o <[email protected]> wrote:
> On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote:
>
>> All the Android community had to do is push the drivers *without*
>> suspend blockers, then the Android kernel wouldn't be so different and
>> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
>> are already in the kernel, so there's no excuse not to merge the
>> drivers.
>
> What's there is not good enough, because it's missing the statistics
> and reporting so that badly behaved kernel and userspace drivers that
> take wakelocks can be found.
You don't need to have all the code merged in, hell, you only needed
wakelock stubs.
You should take the point of view of the community as a whole, and
forget about Android for a second; the important thing is to bring the
code-bases closer, and that means merging the drivers. For that, you
don't need anything extra.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 12:05 PM, Felipe Contreras
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 9:21 PM, Ted Ts'o <[email protected]> wrote:
>> On Thu, Aug 12, 2010 at 07:46:03PM +0300, Felipe Contreras wrote:
>>
>>> All the Android community had to do is push the drivers *without*
>>> suspend blockers, then the Android kernel wouldn't be so different and
>>> thus wouldn't be considered a fork. AFAIU the kernel side wakelocks
>>> are already in the kernel, so there's no excuse not to merge the
>>> drivers.
>>
>> What's there is not good enough, because it's missing the statistics
>> and reporting so that badly behaved kernel and userspace drivers that
>> take wakelocks can be found.
>
> You don't need to have all the code merged in, hell, you only needed
> wakelock stubs.
>
> You should take the point of view of the community as a whole, and
> forget about Android for a second; the important thing is to bring the
> code-bases closer, and that means merging the drivers. For that, you
> don't need anything extra.
Stubs would be 100% fine by me. Previous discussion has indicated
that they are not acceptable without some firm timeline for removal.
I don't think I can commit to a firm removal timeline while we're
still making almost no forward progress.
If we don't have to commit to yanking them back out in two releases or
whatnot, then awesome, let's drop some stubs in and off we go,
worrying about merging drivers that everyone agrees they want.
Question though -- has every feature ever added to the kernel been a
feature that there's pre-existing usage of? Seems like a chicken and
egg problem. Also, some people seem to think there's value in being
able to build kernels "out of the box" that work with the Android
userspace -- given that there are a few devices out there that have
that userspace on 'em.
Brian
Felipe,
> If you think suspend blockers are useful for you, great, use them. I
> just don't see why they should be merged if nobody is going to use
> them but you.
Aren't there many drivers in the kernel sources which are only used by very
few users? Android is used by million users, albeit on one platform, but I
don't see this to be a valid reason to keep this functionality out of the
kernel.
Best,
Dominik
On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
>> So far, nobody has refuted these:
>> 1) opportunistic suspend needs a good behaved user-space to work properly
>
> As does dynamic power management.
Thus remains unrefuted.
>> 2) if suspend blockers are enabled in a system, *all* user-space must
>> implement them to work correctly
>
> Really? From what I can see, only PM-driving applications need to use
> suspend blockers.
"PM-driving applications" is a new invention, so how do you know if an
application belongs to this category or not? Some application might be
non-PM-driving most of the time, but suddenly become PM-driving. Well,
you have to analyze *all* of them.
Think about this... is bash a PM driving application? No, but what if
you run: 'sleep 3600 && alarm.sh'.
Perhaps I should rewrite that as:
2) if suspend blockers are enabled in the system; *all* user-space is affected
>> 3) implementing suspend blockers in user-space is not a straight-forward task
>
> Fortunately, experience thus far has shown that only a small fraction of
> applications need to use suspend blockers.
Wrong. We don't have any experience on that at all on typical linux
ecosystems (remember that Android's user-space is very special).
>> So, as the length of this thread has shown, the benefits of
>> opportunistic suspend are *dubious* at best, and more likely not worth
>> the changes needed in user-space which eventually will get pretty
>> close to what suspend blockers can achieve even in ideal circumstances
>> by just doing dynamic PM.
>
> The length of this thread (and the ones preceding it) is mostly due to
> people talking past each other.
Perhaps half of the thread, or even one quarter of the thread can be
attributed to that, but still the rest I think it's because people
keep pushing in, and people keep pushing out.
> For example, the Android folks seem to
> believe that it is important that relatively unskilled people be able
> to write simple apps, and that the system nevertheless be able to run
> these apps in a relatively energy efficient manner. Your proposals do
> not address this issue. This might be because you are not aware of
> this desire, because you are not aware of the computing history that
> argues in favor of this requirement, or because you simply don't like
> this requirement. Whatever the reason, until you face this requirement
> head on, either addressing it or proving that it need not be addressed,
> you will continue to be talking past the Android folks.
This "requirement" is specific to Android's user-space, isn't it?
Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
user-space seems to be having this problem. I can argue to you that
this problem can be solved in easier ways, but instead I will argue
that perhaps we should wait for somebody besides Android to complain
about it before providing a "solution". Because after all, what good
is a "solution" provided by the kernel, if the user-space is not going
to use it, ever.
--
Felipe Contreras
On Thu, Aug 12, 2010 at 12:34 PM, Felipe Contreras
<[email protected]> wrote:
>
> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> user-space seems to be having this problem. I can argue to you that
> this problem can be solved in easier ways, but instead I will argue
> that perhaps we should wait for somebody besides Android to complain
> about it before providing a "solution". Because after all, what good
> is a "solution" provided by the kernel, if the user-space is not going
> to use it, ever.
I'm curious, when does Android count as a user of the kernel? I
gather that volume of sales or users doesn't count. Do we have to
include some percentage of "desktop" Linux?
If we're an undesirable second-class citizen, why do people care that
"android is forking the kernel"?
I guess I don't understand,
Brian
On Thu, Aug 12, 2010 at 12:48:48PM -0700, Brian Swetland wrote:
> On Thu, Aug 12, 2010 at 12:34 PM, Felipe Contreras
> <[email protected]> wrote:
> >
> > Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> > user-space seems to be having this problem. I can argue to you that
> > this problem can be solved in easier ways, but instead I will argue
> > that perhaps we should wait for somebody besides Android to complain
> > about it before providing a "solution". Because after all, what good
> > is a "solution" provided by the kernel, if the user-space is not going
> > to use it, ever.
>
> I'm curious, when does Android count as a user of the kernel? I
> gather that volume of sales or users doesn't count. Do we have to
> include some percentage of "desktop" Linux?
>
> If we're an undesirable second-class citizen, why do people care that
> "android is forking the kernel"?
>
> I guess I don't understand,
I guess I don't, either -- there are some parts of the kernel used by only a
handful of users... and here we speak about million users...
Best,
Dominik
On Thu, 12 Aug 2010 12:19:34 -0700
Brian Swetland <[email protected]> wrote:
> Question though -- has every feature ever added to the kernel been a
> feature that there's pre-existing usage of? Seems like a chicken and
> egg problem. Also, some people seem to think there's value in being
> able to build kernels "out of the box" that work with the Android
> userspace -- given that there are a few devices out there that have
> that userspace on 'em.
We generally try to merge new features like this along with code that
uses said feature, but there are always exceptions. We've merged code
one release or more before the new code gets used for example, which is
fine IMO. What we don't want to see is some new drop of code added and
abandoned, but you already knew that.
At any rate, if Felipe is the only one arguing against including
suspend blockers in the kernel, you're probably in good shape. Based
on my (rather cursory I admit) evaluation of this thread, it seems like
reasonable people agree that there's a place for a suspend blocker like
API in the kernel, and that dynamic power management is also highly
desirable. So where's the git pull request already? :)
--
Jesse Barnes, Intel Open Source Technology Center
On Thursday, August 12, 2010, Jesse Barnes wrote:
> On Thu, 12 Aug 2010 12:19:34 -0700
> Brian Swetland <[email protected]> wrote:
> > Question though -- has every feature ever added to the kernel been a
> > feature that there's pre-existing usage of? Seems like a chicken and
> > egg problem. Also, some people seem to think there's value in being
> > able to build kernels "out of the box" that work with the Android
> > userspace -- given that there are a few devices out there that have
> > that userspace on 'em.
>
> We generally try to merge new features like this along with code that
> uses said feature, but there are always exceptions. We've merged code
> one release or more before the new code gets used for example, which is
> fine IMO. What we don't want to see is some new drop of code added and
> abandoned, but you already knew that.
>
> At any rate, if Felipe is the only one arguing against including
> suspend blockers in the kernel, you're probably in good shape. Based
> on my (rather cursory I admit) evaluation of this thread, it seems like
> reasonable people agree that there's a place for a suspend blocker like
> API in the kernel, and that dynamic power management is also highly
> desirable. So where's the git pull request already? :)
In fact my patch going in that direction has been merged already and that
code will likely be extended to cover some needs and cases I didn't have in
mind when I was preparing it.
However, having discussed the whole issue for many times and reconsidered it
thoroughly, I think that it's inappropriate to identify the suspend blockers
(or wakelocks) framework with the opportunistic suspend feature as proposed in
the original submission of the "suspend blockers" patchset. IMO they really
are not the same thing and while the suspend blockers framework is used by
Android to implement opportunistic suspend, I don't really believe this is the
right approach.
We really need something similar to suspend blockers to avoid races between
a suspend process and wakeup events, but it isn't necessary to provide user
space with an interface allowing it to use these things directly. Such an
interface is only necessary in the specific implementation in which the system
is suspended as soon as the number of "active" suspend blockers goes down to
zero. Arguably, though, this isn't the only possible way to implement a
mechanism allowing the system to be suspended automatically when it appears
to be inactive.
Namely, one can use a user space power manager for this purpose and actually
the OLPC project has been doing that successfully for some time, which clearly
demonstrates that the Android approach to this problem is not the only one
possible. Moreover, the kernel's system suspend (or hibernate for that matter)
code has not been designed to be started from within the kernel. It's been
designed to allow a privileged user space process to request the kernel to
put the system into a sleep state at any given time regardless of what the
other user space processes are doing. While it can be started from within the
kernel, this isn't particularly nice and, in the Android case, starting it from
within the kernel requires permission from multiple user space processes
(given by not taking suspend blockers these processes are allowed to use).
Since, quite clearly, user space input is necessary to make the decision
whether or not to suspend the system, I think it is more appropriate to allow
user space to start the entire operation and provide the kernel with a means
to abort it in the case of a wakeup event. Then, user space will be able to
use arbitrary heuristics in deciding whether or not to suspend the system,
possibly taking some kernel's input into account.
I'm not against the very idea of automatic system suspend, which IMO is a
legitimate and reasonable thing to do in many usage scenarios, but I don't
think that the kernel is the right place to start a suspend process. For this
reason I'm not going to take any code trying to start a suspend process from
within the kernel, regardless of that code's purpose, unless somebody makes a
really convincing case for that to me (basically proving the need for such a
solution). That said I'm willing to accept patches adding or improving code
that will help us to avoid races between system suspend, initiated by user
space, and wakeup events detected by the kernel.
I hope that makes things clear.
Thanks,
Rafael
On Thu, Aug 12, 2010 at 8:28 PM, Rafael J. Wysocki <[email protected]> wrote:
> On Thursday, August 12, 2010, Jesse Barnes wrote:
>> On Thu, 12 Aug 2010 12:19:34 -0700
>> Brian Swetland <[email protected]> wrote:
>> > Question though -- has every feature ever added to the kernel been a
>> > feature that there's pre-existing usage of? ?Seems like a chicken and
>> > egg problem. ?Also, some people seem to think there's value in being
>> > able to build kernels "out of the box" that work with the Android
>> > userspace -- given that there are a few devices out there that have
>> > that userspace on 'em.
>>
>> We generally try to merge new features like this along with code that
>> uses said feature, but there are always exceptions. ?We've merged code
>> one release or more before the new code gets used for example, which is
>> fine IMO. ?What we don't want to see is some new drop of code added and
>> abandoned, but you already knew that.
>>
>> At any rate, if Felipe is the only one arguing against including
>> suspend blockers in the kernel, you're probably in good shape. ?Based
>> on my (rather cursory I admit) evaluation of this thread, it seems like
>> reasonable people agree that there's a place for a suspend blocker like
>> API in the kernel, and that dynamic power management is also highly
>> desirable. ?So where's the git pull request already? :)
>
> In fact my patch going in that direction has been merged already and that
> code will likely be extended to cover some needs and cases I didn't have in
> mind when I was preparing it.
>
> However, having discussed the whole issue for many times and reconsidered it
> thoroughly, I think that it's inappropriate to identify the suspend blockers
> (or wakelocks) framework with the opportunistic suspend feature as proposed in
> the original submission of the "suspend blockers" patchset. ?IMO they really
> are not the same thing and while the suspend blockers framework is used by
> Android to implement opportunistic suspend, I don't really believe this is the
> right approach.
>
Can you clarify this? Do you not believe using opportunistic suspend
is the right approach, or do you not believe linking suspend blockers
with opportunistic suspend is the right approach?
> We really need something similar to suspend blockers to avoid races between
> a suspend process and wakeup events, but it isn't necessary to provide user
> space with an interface allowing it to use these things directly. ?Such an
> interface is only necessary in the specific implementation in which the system
> is suspended as soon as the number of "active" suspend blockers goes down to
> zero.
I don't think what you are saying here is correct. When you decide to
suspend has no impact on whether a user space interface to block
suspend is needed. The last suspend blocker patchset had this
interface as a separate patch and the reasons for providing it have
not changed with your interface. Android need the user space interface
because low level services that handle wakeup events are started
before the user space power manager. The other reason to have this
interface in the mainline kernel is to provide a safe way to handle
wakeup events on linux regardless of which user space power manager is
used on the system. For instance some devices have a user space
battery monitor, and there would be no need for this code to be
android specific if the kernel provided all the functionality it
needs.
> ?Arguably, though, this isn't the only possible way to implement a
> mechanism allowing the system to be suspended automatically when it appears
> to be inactive.
>
> Namely, one can use a user space power manager for this purpose and actually
> the OLPC project has been doing that successfully for some time, which clearly
> demonstrates that the Android approach to this problem is not the only one
> possible. ?Moreover, the kernel's system suspend (or hibernate for that matter)
> code has not been designed to be started from within the kernel. ?It's been
> designed to allow a privileged user space process to request the kernel to
> put the system into a sleep state at any given time regardless of what the
> other user space processes are doing. ?While it can be started from within the
> kernel, this isn't particularly nice and, in the Android case, starting it from
> within the kernel requires permission from multiple user space processes
> (given by not taking suspend blockers these processes are allowed to use).
>
Why is starting suspend from within the kernel not nice? Personally I
think reentering suspend from within the kernel is nicer than being
forced to wake up a user space thread for events that are fully
handled within the kernel (for instance the battery monitor on the
Nexus One).
> Since, quite clearly, user space input is necessary to make the decision
> whether or not to suspend the system, I think it is more appropriate to allow
> user space to start the entire operation and provide the kernel with a means
> to abort it in the case of a wakeup event. ?Then, user space will be able to
> use arbitrary heuristics in deciding whether or not to suspend the system,
> possibly taking some kernel's input into account.
>
When we don't need these heuristics, this is just a burden.
> I'm not against the very idea of automatic system suspend, which IMO is a
> legitimate and reasonable thing to do in many usage scenarios, but I don't
> think that the kernel is the right place to start a suspend process. ?For this
> reason I'm not going to take any code trying to start a suspend process from
> within the kernel, regardless of that code's purpose, unless somebody makes a
> really convincing case for that to me (basically proving the need for such a
> solution).
There is no absolute need to start the suspend process from within the
kernel, but it makes the user space code much simpler for what we
need.
>?That said I'm willing to accept patches adding or improving code
> that will help us to avoid races between system suspend, initiated by user
> space, and wakeup events detected by the kernel.
>
> I hope that makes things clear.
>
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
--
Arve Hj?nnev?g
rafael j. wysocki wrote:
> On Thursday, August 12, 2010, Jesse Barnes wrote:
> > On Thu, 12 Aug 2010 12:19:34 -0700
> > Brian Swetland <[email protected]> wrote:
> > > Question though -- has every feature ever added to the kernel been a
> > > feature that there's pre-existing usage of? Seems like a chicken and
> > > egg problem. Also, some people seem to think there's value in being
> > > able to build kernels "out of the box" that work with the Android
> > > userspace -- given that there are a few devices out there that have
> > > that userspace on 'em.
> >
> > We generally try to merge new features like this along with code that
> > uses said feature, but there are always exceptions. We've merged code
> > one release or more before the new code gets used for example, which is
> > fine IMO. What we don't want to see is some new drop of code added and
> > abandoned, but you already knew that.
> >
> > At any rate, if Felipe is the only one arguing against including
> > suspend blockers in the kernel, you're probably in good shape. Based
> > on my (rather cursory I admit) evaluation of this thread, it seems like
> > reasonable people agree that there's a place for a suspend blocker like
> > API in the kernel, and that dynamic power management is also highly
> > desirable. So where's the git pull request already? :)
>
> In fact my patch going in that direction has been merged already and that
> code will likely be extended to cover some needs and cases I didn't have in
> mind when I was preparing it.
>
> However, having discussed the whole issue for many times and reconsidered it
> thoroughly, I think that it's inappropriate to identify the suspend blockers
> (or wakelocks) framework with the opportunistic suspend feature as proposed in
> the original submission of the "suspend blockers" patchset. IMO they really
> are not the same thing and while the suspend blockers framework is used by
> Android to implement opportunistic suspend, I don't really believe this is the
> right approach.
>
> We really need something similar to suspend blockers to avoid races between
> a suspend process and wakeup events, but it isn't necessary to provide user
> space with an interface allowing it to use these things directly. Such an
> interface is only necessary in the specific implementation in which the system
> is suspended as soon as the number of "active" suspend blockers goes down to
> zero. Arguably, though, this isn't the only possible way to implement a
> mechanism allowing the system to be suspended automatically when it appears
> to be inactive.
>
> Namely, one can use a user space power manager for this purpose and actually
> the OLPC project has been doing that successfully for some time, which clearly
> demonstrates that the Android approach to this problem is not the only one
hey! how did we get dragged into this? :-)
it's true that OLPC has a user-level power management daemon that
implements our suspend policy. it uses various metrics and
heuristics (i've been told that's latin for "hacks") to decide
when the system is "idle enough" to suspend, along with whether
to leave our independent display running or not, and whether to
leave the wlan active, etc. it does a reasonable job for us for
now, but being intimately familiar with the chewing gum and
string that hold it together, i don't want anyone to think we've
solved a Big Problem.
i do think that there's a place for a flexible user-level policy
engine, no matter how the suspend blockers vs. whatever-else
issue plays out. i guess i assumed that that was a given -- does
android not have such a policy manager? surely there's more to
it than just "last one out, turn out the lights"?
(i should also mention that we definitely see the suspend vs.
wakeup events race issue, and are looking forward to ways to
clean that up.)
paul
> possible. Moreover, the kernel's system suspend (or hibernate for that matter)
> code has not been designed to be started from within the kernel. It's been
> designed to allow a privileged user space process to request the kernel to
> put the system into a sleep state at any given time regardless of what the
> other user space processes are doing. While it can be started from within the
> kernel, this isn't particularly nice and, in the Android case, starting it from
> within the kernel requires permission from multiple user space processes
> (given by not taking suspend blockers these processes are allowed to use).
>
> Since, quite clearly, user space input is necessary to make the decision
> whether or not to suspend the system, I think it is more appropriate to allow
> user space to start the entire operation and provide the kernel with a means
> to abort it in the case of a wakeup event. Then, user space will be able to
> use arbitrary heuristics in deciding whether or not to suspend the system,
> possibly taking some kernel's input into account.
>
> I'm not against the very idea of automatic system suspend, which IMO is a
> legitimate and reasonable thing to do in many usage scenarios, but I don't
> think that the kernel is the right place to start a suspend process. For this
> reason I'm not going to take any code trying to start a suspend process from
> within the kernel, regardless of that code's purpose, unless somebody makes a
> really convincing case for that to me (basically proving the need for such a
> solution). That said I'm willing to accept patches adding or improving code
> that will help us to avoid races between system suspend, initiated by user
> space, and wakeup events detected by the kernel.
>
> I hope that makes things clear.
>
> Thanks,
> Rafael
> _______________________________________________
> linux-pm mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/linux-pm
=---------------------
paul fox, [email protected]
> Why do people care that "android is forking the kernel"?
A lot of us don't. That's what the GPL is about. It's a big pain if you
start splitting it off into two entire things long term - because
your maintenance grows harder exponentially but parallel forks are common
- SuSE and RHEL Enterprise type editions are forks for example.
As far as I can tell it all comes from one or two people with a big PR
presence and almost no code in the kernel saying silly things years ago
which the IT press see as a good way to create a 'we need a column, bash
someone' story.
"What the junk press think" is a common but broken way to run national
policy in some countries, and its just as broken for the kernel.
Alan
> I have a similar problem with the whole pm_qos subsystem, as I've said
> earlier. If some badly behaved application claims to want 0us
> wireless latency, and keeps the radio on all the time, there is no way
> for me to find out which is the badly behaved application --- even
Well firstly you want limits so SELinux says "No" (or rlimit or similar)
and secondly you want sysfs views.
This is like file permissions - its not hard
On Thu, Aug 12, 2010 at 10:52 PM, Dominik Brodowski
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 12:48:48PM -0700, Brian Swetland wrote:
>> I guess I don't understand,
>
> I guess I don't, either -- there are some parts of the kernel used by only a
> handful of users... and here we speak about million users...
A driver that sits in a corner and doesn't show in the 'menuconfig' of
most people and is used by small fraction of user-space applications
(perhaps even 0) is just fine. But we are talking of something
centric, that can be enabled on all systems, and that affects all
user-space.
--
Felipe Contreras
> I guess I don't, either -- there are some parts of the kernel used by only a
> handful of users... and here we speak about million users...
Because in general the bits for a small user base don't leak out into
other bits of the kernel. It's a much higher barrier if you want to
affect other people's code because it is asking everyone else to help
maintain stuff they don't need.
That's not to say sometimes its not the right choice, but I still find it
remarkable that nobody else but Android seems to want it,.
Alan
On Thu, Aug 12, 2010 at 10:48 PM, Brian Swetland <[email protected]> wrote:
> On Thu, Aug 12, 2010 at 12:34 PM, Felipe Contreras
> <[email protected]> wrote:
>>
>> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
>> user-space seems to be having this problem. I can argue to you that
>> this problem can be solved in easier ways, but instead I will argue
>> that perhaps we should wait for somebody besides Android to complain
>> about it before providing a "solution". Because after all, what good
>> is a "solution" provided by the kernel, if the user-space is not going
>> to use it, ever.
>
> I'm curious, when does Android count as a user of the kernel? I
> gather that volume of sales or users doesn't count. Do we have to
> include some percentage of "desktop" Linux?
You are *one* user of the kernel. Let's suppose Android wasn't using
suspend-blockers, and there was another equally successful linux
mobile platform, Foobingo, and they were using them, and they were the
only ones interested on implementing them.
What does that change? Nothing. They still need to convince the
community that what they are proposing to be merged is actually
useful, and somebody will use it. If not, they can just keep the patch
for themselves until they do. I don't see the big deal.
> If we're an undesirable second-class citizen, why do people care that
> "android is forking the kernel"?
Nobody has expressed anything remotely like that (that you are a
second-class citizen). Why makes you think so? Lots of people get
patches denied. Like Nokia's u_char driver, which is *way* less
controversial than this one.
--
Felipe Contreras
> > Think in terms of an ARM laptop. What good is opportunistic suspend if
> > it's not going to help when the laptop is being used?
>
> For when the laptop is not being used, presumably.
Or in time between keystrokes for most of the platform (backlight
excepted). The Intel MID x86 devices are at the point that suspend/resume
time on x86 is being hurt by the kernel rewriting smp alternatives as we
go from 2 processors live to 1 and back.
Alan
On Thu, Aug 12, 2010 at 10:57 PM, Jesse Barnes <[email protected]> wrote:
> On Thu, 12 Aug 2010 12:19:34 -0700
> Brian Swetland <[email protected]> wrote:
>> Question though -- has every feature ever added to the kernel been a
>> feature that there's pre-existing usage of? Seems like a chicken and
>> egg problem. Also, some people seem to think there's value in being
>> able to build kernels "out of the box" that work with the Android
>> userspace -- given that there are a few devices out there that have
>> that userspace on 'em.
>
> We generally try to merge new features like this along with code that
> uses said feature, but there are always exceptions. We've merged code
> one release or more before the new code gets used for example, which is
> fine IMO. What we don't want to see is some new drop of code added and
> abandoned, but you already knew that.
If Android guys provided a bare minimal Debian system with suspend
blockers that people can take a look at and try, I think that would be
a good proof of concept. And a bare minimum to get the patches merged.
> At any rate, if Felipe is the only one arguing against including
> suspend blockers in the kernel, you're probably in good shape. Based
> on my (rather cursory I admit) evaluation of this thread, it seems like
> reasonable people agree that there's a place for a suspend blocker like
> API in the kernel, and that dynamic power management is also highly
> desirable. So where's the git pull request already? :)
I certainly have been the more vocal recently, but if that's confusing
you, I can shut up and let others do the argumentation. I remember at
least Alan Cox, Alan Stern, Thomas Gleixner, Kevin Hilman, Felipe
Balbi, Tony Lindgren, and Igor Stopa against them.
--
Felipe Contreras
On Fri, Aug 13, 2010 at 01:58:12PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 10:48 PM, Brian Swetland <[email protected]> wrote:
> > On Thu, Aug 12, 2010 at 12:34 PM, Felipe Contreras
> > <[email protected]> wrote:
> >>
> >> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> >> user-space seems to be having this problem. I can argue to you that
> >> this problem can be solved in easier ways, but instead I will argue
> >> that perhaps we should wait for somebody besides Android to complain
> >> about it before providing a "solution". Because after all, what good
> >> is a "solution" provided by the kernel, if the user-space is not going
> >> to use it, ever.
> >
> > I'm curious, when does Android count as a user of the kernel? ?I
> > gather that volume of sales or users doesn't count. ?Do we have to
> > include some percentage of "desktop" Linux?
>
> You are *one* user of the kernel. Let's suppose Android wasn't using
> suspend-blockers, and there was another equally successful linux
> mobile platform, Foobingo, and they were using them, and they were the
> only ones interested on implementing them.
>
> What does that change? Nothing. They still need to convince the
> community that what they are proposing to be merged is actually
> useful, and somebody will use it. If not, they can just keep the patch
> for themselves until they do. I don't see the big deal.
So the current users of the Linux kernel are the following?
o GNU/Linux
o Android
Do any other distributions or devices with unusual user-space layouts
qualify?
Thanx, Paul
> > If we're an undesirable second-class citizen, why do people care that
> > "android is forking the kernel"?
>
> Nobody has expressed anything remotely like that (that you are a
> second-class citizen). Why makes you think so? Lots of people get
> patches denied. Like Nokia's u_char driver, which is *way* less
> controversial than this one.
>
> --
> Felipe Contreras
On Friday, August 13, 2010, Arve Hj?nnev?g wrote:
> On Thu, Aug 12, 2010 at 8:28 PM, Rafael J. Wysocki <[email protected]> wrote:
> > On Thursday, August 12, 2010, Jesse Barnes wrote:
> >> On Thu, 12 Aug 2010 12:19:34 -0700
> >> Brian Swetland <[email protected]> wrote:
> >> > Question though -- has every feature ever added to the kernel been a
> >> > feature that there's pre-existing usage of? Seems like a chicken and
> >> > egg problem. Also, some people seem to think there's value in being
> >> > able to build kernels "out of the box" that work with the Android
> >> > userspace -- given that there are a few devices out there that have
> >> > that userspace on 'em.
> >>
> >> We generally try to merge new features like this along with code that
> >> uses said feature, but there are always exceptions. We've merged code
> >> one release or more before the new code gets used for example, which is
> >> fine IMO. What we don't want to see is some new drop of code added and
> >> abandoned, but you already knew that.
> >>
> >> At any rate, if Felipe is the only one arguing against including
> >> suspend blockers in the kernel, you're probably in good shape. Based
> >> on my (rather cursory I admit) evaluation of this thread, it seems like
> >> reasonable people agree that there's a place for a suspend blocker like
> >> API in the kernel, and that dynamic power management is also highly
> >> desirable. So where's the git pull request already? :)
> >
> > In fact my patch going in that direction has been merged already and that
> > code will likely be extended to cover some needs and cases I didn't have in
> > mind when I was preparing it.
> >
> > However, having discussed the whole issue for many times and reconsidered it
> > thoroughly, I think that it's inappropriate to identify the suspend blockers
> > (or wakelocks) framework with the opportunistic suspend feature as proposed in
> > the original submission of the "suspend blockers" patchset. IMO they really
> > are not the same thing and while the suspend blockers framework is used by
> > Android to implement opportunistic suspend, I don't really believe this is the
> > right approach.
> >
>
> Can you clarify this? Do you not believe using opportunistic suspend
> is the right approach, or do you not believe linking suspend blockers
> with opportunistic suspend is the right approach?
The latter. That should be clear from the remaining part of my message.
> > We really need something similar to suspend blockers to avoid races between
> > a suspend process and wakeup events, but it isn't necessary to provide user
> > space with an interface allowing it to use these things directly. Such an
> > interface is only necessary in the specific implementation in which the system
> > is suspended as soon as the number of "active" suspend blockers goes down to
> > zero.
>
> I don't think what you are saying here is correct. When you decide to
> suspend has no impact on whether a user space interface to block
> suspend is needed. The last suspend blocker patchset had this
> interface as a separate patch and the reasons for providing it have
> not changed with your interface. Android need the user space interface
> because low level services that handle wakeup events are started
> before the user space power manager. The other reason to have this
> interface in the mainline kernel is to provide a safe way to handle
> wakeup events on linux regardless of which user space power manager is
> used on the system. For instance some devices have a user space
> battery monitor, and there would be no need for this code to be
> android specific if the kernel provided all the functionality it
> needs.
Well, the problem is, with your /dev/suspend_blocker interface, multiple
user space processes are supposed to decide whether or not system suspend
should be started and in general there don't seem to be any particularly good
criteria for choosing these applications, in general. So, application writers
may be tempted to use this interface in all programs and then the decision
whether or not to allow these programs to affect system power management will
be delegated to users. In turn, the users may not be technically qualified to
make such a decision.
Also the fact that the same mechanism is used for handling wakeup events
detected by the kernel and allowing user space programs to grant permission to
suspend the system is somewhat confusing.
> > Arguably, though, this isn't the only possible way to implement a
> > mechanism allowing the system to be suspended automatically when it appears
> > to be inactive.
> >
> > Namely, one can use a user space power manager for this purpose and actually
> > the OLPC project has been doing that successfully for some time, which clearly
> > demonstrates that the Android approach to this problem is not the only one
> > possible. Moreover, the kernel's system suspend (or hibernate for that matter)
> > code has not been designed to be started from within the kernel. It's been
> > designed to allow a privileged user space process to request the kernel to
> > put the system into a sleep state at any given time regardless of what the
> > other user space processes are doing. While it can be started from within the
> > kernel, this isn't particularly nice and, in the Android case, starting it from
> > within the kernel requires permission from multiple user space processes
> > (given by not taking suspend blockers these processes are allowed to use).
> >
>
> Why is starting suspend from within the kernel not nice? Personally I
> think reentering suspend from within the kernel is nicer than being
> forced to wake up a user space thread for events that are fully
> handled within the kernel (for instance the battery monitor on the
> Nexus One).
For basically the same reason why the kernel generally doesn't use sys_open()
for opening files. It is an interface provided for user space.
> > Since, quite clearly, user space input is necessary to make the decision
> > whether or not to suspend the system, I think it is more appropriate to allow
> > user space to start the entire operation and provide the kernel with a means
> > to abort it in the case of a wakeup event. Then, user space will be able to
> > use arbitrary heuristics in deciding whether or not to suspend the system,
> > possibly taking some kernel's input into account.
> >
> When we don't need these heuristics, this is just a burden.
The word 'arbitrary' means in particular that you can implement a mechanism
equivalent to the /dev/suspend_blocker entirely in user space. Someone else,
though, can use a different approach.
By adding the /dev/suspend_blocker interface to the mainline kernel we would
mandate that Linux applications use it on all platforms. Consequently,
application writers would have the right to expect that all platforms would be
using Android-alike opportunistic suspend, which may or may not be the case.
> > I'm not against the very idea of automatic system suspend, which IMO is a
> > legitimate and reasonable thing to do in many usage scenarios, but I don't
> > think that the kernel is the right place to start a suspend process. For this
> > reason I'm not going to take any code trying to start a suspend process from
> > within the kernel, regardless of that code's purpose, unless somebody makes a
> > really convincing case for that to me (basically proving the need for such a
> > solution).
>
> There is no absolute need to start the suspend process from within the
> kernel, but it makes the user space code much simpler for what we
> need.
I'm entirely aware of that. Still, I think user space is the right place to
initiate system suspend.
Thanks,
Rafael
On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
> >> Anyway, Alan was picturing a hypothetical point in time when x86 can
> >> suspend/resume as fast as ARM, and thus the question of whether or not
> >> to enable suspend-blockers in a system that runs openoffice becomes
> >> relevant. If applications have been fixed by that time to not wake the
> >> system unnecessarily, as many of them have already been tanks to tools
> >> like powertop, then suspend-blockers would not make that much of a
> >> difference, therefore the effort required to implement
> >> suspend-blockers properly on all applications in the system, including
> >> openoffice might not be worth the gain.
> >
> > One more time, this time with feeling. ?;-)
> >
> > ? ? ? ?Only PM-driving applications need concern themselves with suspend
> > ? ? ? ?blockers, and experience thus far indicates that PM-driving
> > ? ? ? ?applications are a very small fraction of the total.
>
> There's no experience on this. Have you tried to run a small debian
> system with suspend blockers enabled? I can image at least all cron
> daemons need modifications, probably dbus, links, lftp, wget, rsync
> and a bunch of applications that download data too.
I have not. I would be surprised if anyone else did that work unless
suspend blockers were in mainline. I would be very happy to be proven
wrong, of course!
> It's easy to speculate one way or the other, but the fact of the
> matter is that we don't really know how many changes are needed in
> order to have a functional system that actually benefits from suspend
> blockers.
>
> What we know is that if an application is not analyzed to see if it
> needs suspend blockers, and implement them if needed, it might get
> broken.
That would be your speculation. Perhaps you are correct, but it seems
more likely that some large sets applications can be considered as a group
rather than one at a time.
> >> > Apparently different people in this debate have different targets.
> >>
> >> I remember clearly Android people explaining that dynamic PM is
> >> orthogonal to suspend-blockers; if a suspend is blocked, you still
> >> want dynamic PM to reach the lower power state. Therefore the target
> >> of not having unneeded runnable tasks is shared by Android folks.
> >
> > And I have not seen anyone argue that suspend blockers are a replacement
> > for dynamic power management.
>
> That's exactly what I'm saying: they are orthogonal.
OK, good to know! Please understand that your sentence "Therefore the
target of not having unneeded runnable tasks is shared by Android folks"
can be interpreted as meaning "the Android guys really don't need suspend
blockers", which is how I interpreted it.
> > In contrast, you are advocating dynamic power management to the exclusion
> > of other mechanisms.
>
> * if dynamic PM was perfect, spend-blockers would *not* be not needed
> * if suspend-blockers were perfect, dynamic *will* still be needed
>
> All I said in that sentence you are replying is that dynamic PM will
> improve; it's a shared goal of everyone.
That is certainly not the way I read the sentence I was replying to,
but I will accept that this was what you were really trying to say.
> >> IOW. Alan wasn't talking about idle vs suspend on the same device, he
> >> was talking about opportunistic suspend vs dynamic PM.
> >
> > The most convincing comparisons will be of suspend vs. idle on the
> > same device. ?If multiple devices are involved, then the most convincing
> > experiments would compare suspend vs. idle separately on each device.
> >
> > So, are you sure that you are correctly interpreting Alan's words?
>
> The point you are trying to highlight is to which events the system
> reacts, that has nothing to do with dynamic PM vs opportunistic
> suspend.
Ahem. I -do- know what -I- was trying to say. ;-)
> > Again, I am in no way arguing for suspend blockers to the exclusion of
> > other approaches. ?Heck, I am mostly just trying to get a clear statement
> > of the problem. ?In contrast, you do seem to be advocating for dynamic
> > power management to the exclusion of other approaches.
>
> What you are doing is copy pasting a definition of what is
> opportunistic suspend and making it pass as an advantage.
No, I was copy pasting a definition of a difference between idle and
suspend and making it pass as a difference between idle and suspend.
> This particular point (3.) is not an advantage, over dynamic PM, it's
> just a difference.
Yep. I never claimed otherwise.
> >> No, I think both (for opportunistic suspend and dynamic PM) are
> >> completely reasonable. But think again; if you have the assumptions
> >> met on both, then both work fine, if you don't meet them, then both
> >> don't work correctly.
> >
> > That is true of any artifact, software or otherwise: if you don't meet the
> > assumptions inherent in its design and construction, the artifact might
> > fail.
>
> [...]
>
> >?There is
> > a very real difference between those two tasks.
>
> I've cut most of your explanation.
Indeed you have! But you should be safe in doing so, as most people
probably won't bother to do the web search that would lead them to
http://lkml.org/lkml/2010/8/12/198 and then search that page for the
word "artifact". ;-)
> If I understand correctly what you
> are saying is that suspend blockers are harder to get wrong. I agree,
> but my point against 4. remains the same: suspend-blockers don't
> automatically get you more efficient power usage.
I am glad you agree that suspend blockers might be harder to get
wrong. As to point #4, you were correct that I badly worded the last
sentence, which is now hopefully fixed to your satisfaction.
> > So are you sure that dynamic power management will turn out to be
> > the right tool for every job out there? ?If so, on what grounds?
>
> I don't understand this question. Dynamic PM is needed regardless. We
> are discussing your point 4 where you say suspend blockers inevitably
> lead to more efficient power usage (I say not necessarily).
But can dynamic power management do everything optimally? If not, some
other approach may be needed in addition to dynamic power management.
If you really are arguing that the Linux kernel should support no
power-management mechanism other than dynamic power management, you
should be prepared to justify that position.
> >> My point is that suspend-blockers don't magically reduce power usage,
> >> just like dynamic PM, it depends on what user-space actually does. You
> >> made it look as it *always* reached better energy efficiency.
> >
> > I do? ?Really??? ?Exactly what did I say to give you that impression?
>
> Here's your point 4 again:
>
> > >> > 4. Suspend generally forces devices to go into their low-power
> > >> > states immediately. In contrast, idle generally leaves unused
> > >> > devices at full power, relying on timers to shut down these
> > >> > devices. Idle thus has shorter average wakeup latencies, but
> > >> > worse energy efficiency.
>
> Remove "but worse energy efficiency" and I think that point would be
> correct, albeit it's not really an argument in favor of opportunistic
> suspend.
Fix put forward in earlier email. Again, thank you -- good catch!!!
> >> > It seems to me that the same social-engineering approaches work in
> >> > both cases.
> >>
> >> Yes, but if dynamic PM works as advertised, you don't need
> >> opportunistic suspend.
> >
> > For dynamic power management to totally eliminate the need for something
> > like suspend blockers, you are having to make some brave assumptions.
> > Yes, dynamic power management is quite useful, but there is a big
> > difference between something being useful and something doing everything
> > for everyone. ?You have not yet convinced me that dynamic power management
> > will make it to the "doing everything for everyone" stage.
>
> As it has been explained before, there's a sweet-spot of idleness:
> http://article.gmane.org/gmane.linux.kernel/995525
> http://article.gmane.org/gmane.linux.ports.arm.omap/37982
>
> Do you agree that there's such a thing, and if so, do you agree that
> the benefits of opportunistic suspend are much less once that point is
> reached?
I agree that there will be a sweet spot of idleness (though I would call
it a "point of diminishing returns"), but only if all the applications
are power-optimized. The advantage of opportunistic suspend is instead
its tolerance of power-oblivious applications with minimal degradation
of battery life.
> >> >> If not, you'll see much worst energy efficiency. So in theory maybe,
> >> >> but in practice you can't say that.
> >> >
> >> > Really? ?What makes you say that?
> >>
> >> For starters an application might be holding the wakelock more than it
> >> should, also, an application might miss a timer due to not having PM
> >> permissions to hold the lock, and thus might need an expensive
> >> initialization when it runs again.
> >
> > Just as an application might run continuously without blocking, which
> > would defeat the dynamic power management scheme that have thus far been
> > put forward. ?And just as an application might miss a timer due to
> > dynamic power management having decided that it didn't need that timer
> > to fire at the desired time.
>
> You are making this discussion entropic, concentrate on what I said:
> >>>> If not, you'll see much worst energy efficiency. So in theory maybe,
> >>>> but in practice you can't say that.
>
> I just proved to you that in certain cases opportunistic suspend might
> actually hurt. Thus you should accept my premise that you can't say
> that in practice opportunistic suspend _always_ leads to better
> results, because that's not the case.
And in the paragraph above, I proved to you that relying solely on dynamic
power management might actually hurt. And I am not trying to prove
that opportunistic suspend always leads to better results -- that is a
strawman that you set up. And yes, you might have been led to set up that
strawman because I messed up the wording of one of the suspend-vs.-idle
definitions. Of course, had you called out that sentence to start with,
we would likely have spent much less time arguing generalities. ;-)
> And in order to try to avoid going back to the same points:
> 1) yes, there are advantages of opportunistic suspend
Good, agreed.
> 2) yes, there are cases where it works as it should
Good, agreed.
> 3) no, it's not a silver bullet that will inevitably improve power usage
Agreed. This is no surprise, as there are very few silver bullets to be
had in this field. Of course, dynamic power management is not a silver
bullet, either.
> 4) no, we can't say anything about what opportunistic suspend means in practice
Here I disagree. The Android folks have used it for quite some time.
We might not be able to apply their experience directly to other software
stacks, but we should nevertheless be able to learn quite a bit from it.
Thanx, Paul
On Thu, Aug 12, 2010 at 10:34:47PM +0300, Felipe Contreras wrote:
> On Thu, Aug 12, 2010 at 8:43 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Thu, Aug 12, 2010 at 02:11:22PM +0300, Felipe Contreras wrote:
> >> So far, nobody has refuted these:
> >> ?1) opportunistic suspend needs a good behaved user-space to work properly
> >
> > As does dynamic power management.
>
> Thus remains unrefuted.
Glad we agree that both dynamic power management and opportunistic
power management need applications to be written carefully. Of course,
dynamic power management requires all of the code in those applications
to be carefully written, while experience indicates that opportunistic
suspend requires only a small fraction to be carefully written.
> >> ?2) if suspend blockers are enabled in a system, *all* user-space must
> >> implement them to work correctly
> >
> > Really? ?From what I can see, only PM-driving applications need to use
> > suspend blockers.
>
> "PM-driving applications" is a new invention, so how do you know if an
> application belongs to this category or not? Some application might be
> non-PM-driving most of the time, but suddenly become PM-driving. Well,
> you have to analyze *all* of them.
A PM-driving application is one that exerts control over the system's
power state. In the case of Android, a PM-driving application is one
that is permitted to acquire suspend blockers.
> Think about this... is bash a PM driving application? No, but what if
> you run: 'sleep 3600 && alarm.sh'.
That is an excellent example, as it applies equally to dynamic power
management. By how much are you allowed to delay the wakeup?
> Perhaps I should rewrite that as:
> 2) if suspend blockers are enabled in the system; *all* user-space is affected
That is speculation on your part.
> >> ?3) implementing suspend blockers in user-space is not a straight-forward task
> >
> > Fortunately, experience thus far has shown that only a small fraction of
> > applications need to use suspend blockers.
>
> Wrong. We don't have any experience on that at all on typical linux
> ecosystems (remember that Android's user-space is very special).
Android's experience might not apply exactly to typical Linux ecosystems,
but we really can learn quite a bit from it -- at least if we can bring
ourselves to do so.
> >> So, as the length of this thread has shown, the benefits of
> >> opportunistic suspend are *dubious* at best, and more likely not worth
> >> the changes needed in user-space which eventually will get pretty
> >> close to what suspend blockers can achieve even in ideal circumstances
> >> by just doing dynamic PM.
> >
> > The length of this thread (and the ones preceding it) is mostly due to
> > people talking past each other.
>
> Perhaps half of the thread, or even one quarter of the thread can be
> attributed to that, but still the rest I think it's because people
> keep pushing in, and people keep pushing out.
Fair enough. I wasn't differentiating between people mistakenly talking
past each other and intentionally talking past each other, but if you
want to differentiate, feel free to do so.
> > For example, the Android folks seem to
> > believe that it is important that relatively unskilled people be able
> > to write simple apps, and that the system nevertheless be able to run
> > these apps in a relatively energy efficient manner. ?Your proposals do
> > not address this issue. ?This might be because you are not aware of
> > this desire, because you are not aware of the computing history that
> > argues in favor of this requirement, or because you simply don't like
> > this requirement. ?Whatever the reason, until you face this requirement
> > head on, either addressing it or proving that it need not be addressed,
> > you will continue to be talking past the Android folks.
>
> This "requirement" is specific to Android's user-space, isn't it?
That is your speculation.
> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> user-space seems to be having this problem. I can argue to you that
> this problem can be solved in easier ways, but instead I will argue
> that perhaps we should wait for somebody besides Android to complain
> about it before providing a "solution". Because after all, what good
> is a "solution" provided by the kernel, if the user-space is not going
> to use it, ever.
At this point in the discussion, I am quite prepared to believe that you
will avoid using suspend blockers, and that you will further do everything
in your power to prevent anyone else from using suspend blockers. ;-)
Thanx, Paul
On Fri, Aug 13, 2010 at 6:14 PM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
>> 4) no, we can't say anything about what opportunistic suspend means in practice
>
> Here I disagree. The Android folks have used it for quite some time.
> We might not be able to apply their experience directly to other software
> stacks, but we should nevertheless be able to learn quite a bit from it.
So when it comes to practice you are relying solely on what Android people say.
If it's true that it's easy to spot the "PM-driving applications",
then it shouldn't be hard for a guy from the Android team to assemble
a basic typical system (X.org, dbus, etc.) with suspend-blockers in a
couple of days.
--
Felipe Contreras
On Fri, Aug 13, 2010 at 11:57:51AM +0100, Alan Cox wrote:
> > > Think in terms of an ARM laptop. What good is opportunistic suspend if
> > > it's not going to help when the laptop is being used?
> >
> > For when the laptop is not being used, presumably.
>
> Or in time between keystrokes for most of the platform (backlight
> excepted). The Intel MID x86 devices are at the point that suspend/resume
> time on x86 is being hurt by the kernel rewriting smp alternatives as we
> go from 2 processors live to 1 and back.
Given that you are talking about going from 2 processors to 1 and back,
I would guess that you are not actually talking about suspend/resume,
which is a system-wide thing rather than a CPU-by-CPU thing. I am not
sure whether you are using CPU hotplug or invoking SMP alternatives once
all but one CPU is idle.
Can't say that I can tell exactly what pit you are digging for me here. ;-)
Thanx, Paul
On Fri, Aug 13, 2010 at 6:22 PM, Paul E. McKenney
<[email protected]> wrote:
> On Thu, Aug 12, 2010 at 10:34:47PM +0300, Felipe Contreras wrote:
>> "PM-driving applications" is a new invention, so how do you know if an
>> application belongs to this category or not? Some application might be
>> non-PM-driving most of the time, but suddenly become PM-driving. Well,
>> you have to analyze *all* of them.
>
> A PM-driving application is one that exerts control over the system's
> power state. In the case of Android, a PM-driving application is one
> that is permitted to acquire suspend blockers.
I already mentioned that a "PM-driving application" might not have
suspend-blockers; because the user denied them, or because the
developer forgot them.
>> Think about this... is bash a PM driving application? No, but what if
>> you run: 'sleep 3600 && alarm.sh'.
>
> That is an excellent example, as it applies equally to dynamic power
> management. By how much are you allowed to delay the wakeup?
Huh? Certainly not days, which if Android guys are right, might be how
much the task will be delayed.
>> Perhaps I should rewrite that as:
>> 2) if suspend blockers are enabled in the system; *all* user-space is affected
>
> That is speculation on your part.
Not really. Say you have 100 packages in your system, how do you know
which ones would be PM-driving? Can you grep for something, or see if
they open certain file? No, you have to analyze them one by one; they
*all* are affected, although not all might require modifications.
But assuming I'm wrong, that's precisely the reason why a practical
exercise would help.
>> This "requirement" is specific to Android's user-space, isn't it?
>
> That is your speculation.
Which is why we need something practical.
>> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
>> user-space seems to be having this problem. I can argue to you that
>> this problem can be solved in easier ways, but instead I will argue
>> that perhaps we should wait for somebody besides Android to complain
>> about it before providing a "solution". Because after all, what good
>> is a "solution" provided by the kernel, if the user-space is not going
>> to use it, ever.
>
> At this point in the discussion, I am quite prepared to believe that you
> will avoid using suspend blockers, and that you will further do everything
> in your power to prevent anyone else from using suspend blockers. ;-)
I'm not tying anybody's hands.
How are people using real-time linux if it's not on mainline? Well,
duuh, you apply the patches. If say Fedora was interested on it, they
could apply the patches, and see for themselves. People do that all
the time, with the mm tree, with Con Koliva's patches, etc. Once
people are happy with the results, things get merged. Why should this
be any different?
--
Felipe Contreras
> >> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> >> user-space seems to be having this problem. I can argue to you that
> >> this problem can be solved in easier ways, but instead I will argue
> >> that perhaps we should wait for somebody besides Android to complain
> >> about it before providing a "solution". Because after all, what good
> >> is a "solution" provided by the kernel, if the user-space is not going
> >> to use it, ever.
> >
> > At this point in the discussion, I am quite prepared to believe that you
> > will avoid using suspend blockers, and that you will further do everything
> > in your power to prevent anyone else from using suspend blockers. ?;-)
>
> I'm not tying anybody's hands.
>
> How are people using real-time linux if it's not on mainline? Well,
> duuh, you apply the patches. If say Fedora was interested on it, they
> could apply the patches, and see for themselves. People do that all
> the time, with the mm tree, with Con Koliva's patches, etc. Once
> people are happy with the results, things get merged. Why should this
> be any different?
Because millions of users are happy -- with Android, including suspend
blockers.
Best,
Dominik
On Fri, 2010-08-13 at 17:57 +0200, Dominik Brodowski wrote:
> Because millions of users are happy -- with Android, including suspend
> blockers.
I'd guess there are on the order of 20 users
that have built and deployed a kernel with
Android suspend blockers support.
The total deployed systems is relatively meaningless.
On Fri, Aug 13, 2010 at 09:06:47AM -0700, Joe Perches wrote:
> On Fri, 2010-08-13 at 17:57 +0200, Dominik Brodowski wrote:
> > Because millions of users are happy -- with Android, including suspend
> > blockers.
>
> I'd guess there are on the order of 20 users
> that have built and deployed a kernel with
> Android suspend blockers support.
You mean non-Google users?
> The total deployed systems is relatively meaningless.
Well, it wasn't meaningless wrt noveau:
"I've heard all the excuses. If it isn't ready, they shouldn't ship it to
millions of people. And if it's ready, they should work on merging it.
No excuses.
Linus"
So let's get the suspend blockers to Linus.
Best
Dominik
On Fri, Aug 13, 2010 at 6:57 PM, Dominik Brodowski
<[email protected]> wrote:
>> >> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
>> >> user-space seems to be having this problem. I can argue to you that
>> >> this problem can be solved in easier ways, but instead I will argue
>> >> that perhaps we should wait for somebody besides Android to complain
>> >> about it before providing a "solution". Because after all, what good
>> >> is a "solution" provided by the kernel, if the user-space is not going
>> >> to use it, ever.
>> >
>> > At this point in the discussion, I am quite prepared to believe that you
>> > will avoid using suspend blockers, and that you will further do everything
>> > in your power to prevent anyone else from using suspend blockers. ;-)
>>
>> I'm not tying anybody's hands.
>>
>> How are people using real-time linux if it's not on mainline? Well,
>> duuh, you apply the patches. If say Fedora was interested on it, they
>> could apply the patches, and see for themselves. People do that all
>> the time, with the mm tree, with Con Koliva's patches, etc. Once
>> people are happy with the results, things get merged. Why should this
>> be any different?
>
> Because millions of users are happy -- with Android, including suspend
> blockers.
I explicitly said somebody besides Android, specifically, somebody
with a typical linux ecosystem. You are not addressing the argument at
hand, that nobody else wants to tackle the issue this way, thus only
making the discussion more difficult.
--
Felipe Contreras
On Fri, 13 Aug 2010 05:28:21 +0200
"Rafael J. Wysocki" <[email protected]> wrote:
> On Thursday, August 12, 2010, Jesse Barnes wrote:
> > On Thu, 12 Aug 2010 12:19:34 -0700
> > Brian Swetland <[email protected]> wrote:
> > > Question though -- has every feature ever added to the kernel been a
> > > feature that there's pre-existing usage of? Seems like a chicken and
> > > egg problem. Also, some people seem to think there's value in being
> > > able to build kernels "out of the box" that work with the Android
> > > userspace -- given that there are a few devices out there that have
> > > that userspace on 'em.
> >
> > We generally try to merge new features like this along with code that
> > uses said feature, but there are always exceptions. We've merged code
> > one release or more before the new code gets used for example, which is
> > fine IMO. What we don't want to see is some new drop of code added and
> > abandoned, but you already knew that.
> >
> > At any rate, if Felipe is the only one arguing against including
> > suspend blockers in the kernel, you're probably in good shape. Based
> > on my (rather cursory I admit) evaluation of this thread, it seems like
> > reasonable people agree that there's a place for a suspend blocker like
> > API in the kernel, and that dynamic power management is also highly
> > desirable. So where's the git pull request already? :)
>
> In fact my patch going in that direction has been merged already and that
> code will likely be extended to cover some needs and cases I didn't have in
> mind when I was preparing it.
Yeah, I like what you've done with dynamic power management, really
good stuff (the approach is very similar to the one I used for vblank
interrupt management in the drm layer).
Ted's point about providing the user with a way of knowing which apps
are blocking things is a good one though, and doesn't seem too hard to
add. It might even be possible to do it largely with scripts wrapping
fuser and such.
> However, having discussed the whole issue for many times and reconsidered it
> thoroughly, I think that it's inappropriate to identify the suspend blockers
> (or wakelocks) framework with the opportunistic suspend feature as proposed in
> the original submission of the "suspend blockers" patchset. IMO they really
> are not the same thing and while the suspend blockers framework is used by
> Android to implement opportunistic suspend, I don't really believe this is the
> right approach.
>
> We really need something similar to suspend blockers to avoid races between
> a suspend process and wakeup events, but it isn't necessary to provide user
> space with an interface allowing it to use these things directly. Such an
> interface is only necessary in the specific implementation in which the system
> is suspended as soon as the number of "active" suspend blockers goes down to
> zero. Arguably, though, this isn't the only possible way to implement a
> mechanism allowing the system to be suspended automatically when it appears
> to be inactive.
>
> Namely, one can use a user space power manager for this purpose and actually
> the OLPC project has been doing that successfully for some time, which clearly
> demonstrates that the Android approach to this problem is not the only one
> possible. Moreover, the kernel's system suspend (or hibernate for that matter)
> code has not been designed to be started from within the kernel. It's been
> designed to allow a privileged user space process to request the kernel to
> put the system into a sleep state at any given time regardless of what the
> other user space processes are doing. While it can be started from within the
> kernel, this isn't particularly nice and, in the Android case, starting it from
> within the kernel requires permission from multiple user space processes
> (given by not taking suspend blockers these processes are allowed to use).
Yes, I see your point. But I actually think this is a fairly minor
distinction. In one case, a privileged app decides when to suspend the
system, in the other case, one or more of several privileged apps
decide when a suspend should not be allowed to occur. It's just a
matter of where you want to put the code and where you want the
complexity. In general, we try to keep such complexity out of the
kernel, but not always; there are compelling cases for putting
complexity in the kernel to provide uniformity and flexibility (e.g.
application state save/restore vs. system-wide checkpoints, the former
preserves the "if it can be done outside the kernel, it should be",
while the latter provides much greater flexibility and avoids the need
to port applications to potentially incompatible or unportable state
saves/restore libraries).
--
Jesse Barnes, Intel Open Source Technology Center
On Fri, 2010-08-13 at 19:19 +0300, Felipe Contreras wrote:
> On Fri, Aug 13, 2010 at 6:57 PM, Dominik Brodowski
> <[email protected]> wrote:
> >> >> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
> >> >> user-space seems to be having this problem. I can argue to you that
> >> >> this problem can be solved in easier ways, but instead I will argue
> >> >> that perhaps we should wait for somebody besides Android to complain
> >> >> about it before providing a "solution". Because after all, what good
> >> >> is a "solution" provided by the kernel, if the user-space is not going
> >> >> to use it, ever.
> >> >
> >> > At this point in the discussion, I am quite prepared to believe that you
> >> > will avoid using suspend blockers, and that you will further do everything
> >> > in your power to prevent anyone else from using suspend blockers. ;-)
> >>
> >> I'm not tying anybody's hands.
> >>
> >> How are people using real-time linux if it's not on mainline? Well,
> >> duuh, you apply the patches. If say Fedora was interested on it, they
> >> could apply the patches, and see for themselves. People do that all
> >> the time, with the mm tree, with Con Koliva's patches, etc. Once
> >> people are happy with the results, things get merged. Why should this
> >> be any different?
> >
> > Because millions of users are happy -- with Android, including suspend
> > blockers.
>
> I explicitly said somebody besides Android, specifically, somebody
> with a typical linux ecosystem. You are not addressing the argument at
> hand, that nobody else wants to tackle the issue this way, thus only
> making the discussion more difficult.
Can we stop arguing about the pointless?
The facts are that suspend blockers identifies a race within our suspend
to ram system that permeates from top to bottom (that's from server to
mobile). The problem is that resume events are racy with respect to
suspend and vice versa. This manifests itself most annoyingly on my
laptop in the "double suspend" case: where I suspend with a pending
suspend event, my laptop will resume and then immediately re-suspend
(leading me to kick myself and remind myself to check it stayed up
before pushing unsuspend and walking away). The other annoying case is
that if I accidentally close the lid before presenting, I have to wait
until the system is fully down before pressing resume.
In a Data Centre controlling power, if you sent a suspend then a wake on
lan, there's a window where the machine will still be down (because the
wol got ignored).
There are easy fixes to all the above ... I should wait to verify
suspend and resume in my laptop and I have to accept the wait time
between the two. In the data centre, you just repeat your power control
commands a few times with about 5s between them and so on.
The simple hacky work arounds mean that a user space invasive solution
like suspend blockers is a bit of a non starter as a solution to the
general case. However, it has shown that we do have a problem and
furthermore it's a problem encountered by more than android.
The technical problem with suspend blockers is that they're a solution
to a general problem that only works for a specific case. What we're
searching for is a general solution that can also be used in the android
specific case.
So far, we have three possibilities:
1. Stubs with deprecation - this has been rejected by android, so
looks like a non starter.
2. update pm_qos so that the suspend blocks become qos constraints.
This may or may not be coupled with a user space suspend
manager, but in the latter case it's essentially full suspend
blockers (with the additional opportunistic suspend kernel code)
but with information systems outside of android can use.
3. Rafael's patch that makes it possible to avoid the races between
wakeup and suspend. This requires a user space suspend manager
(There's a whole other load of implementation details like stats and the
like, but the above is the concept view).
Unless anyone has something substantive to add to either the problem
space or the solution space, the android discussion piece of this thread
has degenerated to pure noise.
James
On Fri, Aug 13, 2010 at 06:28:27PM +0300, Felipe Contreras wrote:
> On Fri, Aug 13, 2010 at 6:14 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
> >> ?4) no, we can't say anything about what opportunistic suspend means in practice
> >
> > Here I disagree. ?The Android folks have used it for quite some time.
> > We might not be able to apply their experience directly to other software
> > stacks, but we should nevertheless be able to learn quite a bit from it.
>
> So when it comes to practice you are relying solely on what Android people say.
So when it comes to practice with suspend blockers, only the Android
people have any experience, so theirs is the only experience with
suspend blockers that there is to rely on. ;-) ;-) ;-)
> If it's true that it's easy to spot the "PM-driving applications",
> then it shouldn't be hard for a guy from the Android team to assemble
> a basic typical system (X.org, dbus, etc.) with suspend-blockers in a
> couple of days.
I am happy to let the Android guys determine the best use for their time.
Thanx, Paul
On Fri, Aug 13, 2010 at 01:11:29PM -0400, James Bottomley wrote:
>
> The facts are that suspend blockers identifies a race within our suspend
> to ram system that permeates from top to bottom (that's from server to
> mobile). The problem is that resume events are racy with respect to
> suspend and vice versa. This manifests itself most annoyingly on my
> laptop in the "double suspend" case: where I suspend with a pending
> suspend event, my laptop will resume and then immediately re-suspend
> (leading me to kick myself and remind myself to check it stayed up
> before pushing unsuspend and walking away). The other annoying case is
> that if I accidentally close the lid before presenting, I have to wait
> until the system is fully down before pressing resume.
This is all true, but it's also only one aspect of the problem. I
agree with you that this is the part of the problem which affects
Linux at all scales, from Cloud servers in a data center that want to
suspend themselves when there's no work to do (and then fail to
respond to the WOL packet) to mobile platforms that are suspending
much more frequently.
However, it doesn't follow that this is the _only_ problem that the
Android folks might be interested in solving. Opportunistic suspend
is a different part of the problem space, which is generally believed
by the Android developers as being far more efficient than a
user-space suspend manager. Rafael has stated his complete
unwillingness to deal with this part of the problem. OK, so that
probably means that for Android, it will have to be an out-of-tree
kernel patch.
The question, then, is whether a solution which addresses the only
part of the problem which Rafael is interested in dealing with at this
point, is sufficient such that (a) the kernel-level opportunistic
suspend can be done as an out-of-tree patch, while simultaneously (b)
allowing device drivers for Android devices can utilize Rafael's
interfaces to solve the race design bug currently found in our suspend
subsystem, while (c) requiring minimal changes to the Android
userspace, and (d) providing all of the statistics and debugging
functionality required by the Android userspace.
If we can engineer a solution which meets (a), (b), (c), and (d)
above, then everyone will be happy.
- Ted
On Fri, Aug 13, 2010 at 12:08 PM, Ted Ts'o <[email protected]> wrote:
> On Fri, Aug 13, 2010 at 01:11:29PM -0400, James Bottomley wrote:
>>
>> The facts are that suspend blockers identifies a race within our suspend
>> to ram system that permeates from top to bottom (that's from server to
>> mobile). The problem is that resume events are racy with respect to
>> suspend and vice versa. This manifests itself most annoyingly on my
>> laptop in the "double suspend" case: where I suspend with a pending
>> suspend event, my laptop will resume and then immediately re-suspend
>> (leading me to kick myself and remind myself to check it stayed up
>> before pushing unsuspend and walking away). The other annoying case is
>> that if I accidentally close the lid before presenting, I have to wait
>> until the system is fully down before pressing resume.
>
> This is all true, but it's also only one aspect of the problem. I
> agree with you that this is the part of the problem which affects
> Linux at all scales, from Cloud servers in a data center that want to
> suspend themselves when there's no work to do (and then fail to
> respond to the WOL packet) to mobile platforms that are suspending
> much more frequently.
>
> However, it doesn't follow that this is the _only_ problem that the
> Android folks might be interested in solving. Opportunistic suspend
> is a different part of the problem space, which is generally believed
> by the Android developers as being far more efficient than a
> user-space suspend manager. Rafael has stated his complete
> unwillingness to deal with this part of the problem. OK, so that
> probably means that for Android, it will have to be an out-of-tree
> kernel patch.
>
> The question, then, is whether a solution which addresses the only
> part of the problem which Rafael is interested in dealing with at this
> point, is sufficient such that (a) the kernel-level opportunistic
> suspend can be done as an out-of-tree patch, while simultaneously (b)
> allowing device drivers for Android devices can utilize Rafael's
> interfaces to solve the race design bug currently found in our suspend
> subsystem, while (c) requiring minimal changes to the Android
> userspace, and (d) providing all of the statistics and debugging
> functionality required by the Android userspace.
>
> If we can engineer a solution which meets (a), (b), (c), and (d)
> above, then everyone will be happy.
Arve's suspend blockers patch stack actually separates the core
functionality (ability for drivers to delay suspend while doing work
suspend would interfere with), from the ability to hold suspend
blockers from userspace (a separate, smaller patch building on the
core functionality).
Brian
On Fri, 2010-08-13 at 15:08 -0400, Ted Ts'o wrote:
> On Fri, Aug 13, 2010 at 01:11:29PM -0400, James Bottomley wrote:
> >
> > The facts are that suspend blockers identifies a race within our suspend
> > to ram system that permeates from top to bottom (that's from server to
> > mobile). The problem is that resume events are racy with respect to
> > suspend and vice versa. This manifests itself most annoyingly on my
> > laptop in the "double suspend" case: where I suspend with a pending
> > suspend event, my laptop will resume and then immediately re-suspend
> > (leading me to kick myself and remind myself to check it stayed up
> > before pushing unsuspend and walking away). The other annoying case is
> > that if I accidentally close the lid before presenting, I have to wait
> > until the system is fully down before pressing resume.
>
> This is all true, but it's also only one aspect of the problem. I
> agree with you that this is the part of the problem which affects
> Linux at all scales, from Cloud servers in a data center that want to
> suspend themselves when there's no work to do (and then fail to
> respond to the WOL packet) to mobile platforms that are suspending
> much more frequently.
>
> However, it doesn't follow that this is the _only_ problem that the
> Android folks might be interested in solving. Opportunistic suspend
> is a different part of the problem space, which is generally believed
> by the Android developers as being far more efficient than a
> user-space suspend manager. Rafael has stated his complete
> unwillingness to deal with this part of the problem. OK, so that
> probably means that for Android, it will have to be an out-of-tree
> kernel patch.
OK, so I tried desperately to avoid the question of whether
opportunistic suspend is a good way of managing power. However, it
seems to me that it is in use by several systems (android, olpc, etc).
I'll defer the question of whether it's better in user space or kernel
space to Rafael's investigations ... but I will point out that the
kernel space patch, once the suspend blockers issue is taken care of
looks like a single patch to one file, so should be locally containable
and should allow upstream to be useful as the driver base again.
> The question, then, is whether a solution which addresses the only
> part of the problem which Rafael is interested in dealing with at this
> point, is sufficient such that (a) the kernel-level opportunistic
> suspend can be done as an out-of-tree patch, while simultaneously (b)
> allowing device drivers for Android devices can utilize Rafael's
> interfaces to solve the race design bug currently found in our suspend
> subsystem, while (c) requiring minimal changes to the Android
> userspace, and (d) providing all of the statistics and debugging
> functionality required by the Android userspace.
>
> If we can engineer a solution which meets (a), (b), (c), and (d)
> above, then everyone will be happy.
That's my goal.
James
On Fri, 13 Aug 2010 17:07:02 +0200
"Rafael J. Wysocki" <[email protected]> wrote:
> >
> > There is no absolute need to start the suspend process from within the
> > kernel, but it makes the user space code much simpler for what we
> > need.
>
> I'm entirely aware of that. Still, I think user space is the right place to
> initiate system suspend.
>
For what it's worth - I completely agree.
Clearly there is no a lot of unanimity on this, and so lots of room to
experiment with different approaches. It's best if we leave as much as
possible of that experimentation in user-space - just have the kernel do what
cannot be done elsewhere.
NeilBrown
Hi!
> > > > Think in terms of an ARM laptop. What good is opportunistic suspend if
> > > > it's not going to help when the laptop is being used?
> > >
> > > For when the laptop is not being used, presumably.
> >
> > Or in time between keystrokes for most of the platform (backlight
> > excepted). The Intel MID x86 devices are at the point that suspend/resume
> > time on x86 is being hurt by the kernel rewriting smp alternatives as we
> > go from 2 processors live to 1 and back.
>
> Given that you are talking about going from 2 processors to 1 and back,
> I would guess that you are not actually talking about suspend/resume,
> which is a system-wide thing rather than a CPU-by-CPU thing. I am not
> sure whether you are using CPU hotplug or invoking SMP alternatives once
> all but one CPU is idle.
When entering system suspend, we disable non-boot-CPUs to simplify
locking. We reenable them when going out of suspend.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu 2010-08-12 08:52:49, Ted Ts'o wrote:
> On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
> >
> > The question is why are we adding a user-space API that:
> > 1) no user-space beside Android has expresses interest in implementing
> > 2) is dubious whether the benefits are worth the pain for non-Android
> > user-space
> > 3) will become less and less attractive as dynamic PM gets closer to
> > the sweet-spot, and then surpass it
> > 4) Android can keep in a separate tree until it's clear in the linux
> > community that it's useful (if it ever happens)
>
> So, Felipe,
>
> Do you believe you speak for all of LKML?
>
> Are you willing to tell ZDNet and the Slashdot fanboys that it's OK
> for Suspend blockers to live in a separate tree, and it's not a case
> of OMG! Google is forking the kernel?
>
> If you could speak out a passionately on those forums as you have
> here, that would be great.
Ted, what is going on here? Are you suggesting people disagreeing with
Google patches suddenly have to do advocacy for Google?
And yes, for the record Felipe speaks for me pretty well.
Normal path of merging stuff to the kernel is
"Google develops it, then modifies it to address the review comments,
then it is merged, then it is deployed".
Unfortunately what Google did here is:
"Google develops it behind the closed door, then deploys it. When
asked for changes, Google expects someone else to create system
compatible with their existing solution, or else their patches being
merged."
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> >> Question though -- has every feature ever added to the kernel been a
> >> feature that there's pre-existing usage of? ?Seems like a chicken and
> >> egg problem. ?Also, some people seem to think there's value in being
> >> able to build kernels "out of the box" that work with the Android
> >> userspace -- given that there are a few devices out there that have
> >> that userspace on 'em.
> >
> > We generally try to merge new features like this along with code that
> > uses said feature, but there are always exceptions. ?We've merged code
> > one release or more before the new code gets used for example, which is
> > fine IMO. ?What we don't want to see is some new drop of code added and
> > abandoned, but you already knew that.
>
> If Android guys provided a bare minimal Debian system with suspend
> blockers that people can take a look at and try, I think that would be
> a good proof of concept. And a bare minimum to get the patches merged.
Yes, that would certainly help.
I guess this is the major point -- as suspend blockers seem very
suitable for android, they don't seem suitable for anyone else...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > ?Arguably, though, this isn't the only possible way to implement a
> > mechanism allowing the system to be suspended automatically when it appears
> > to be inactive.
> >
> > Namely, one can use a user space power manager for this purpose and actually
> > the OLPC project has been doing that successfully for some time, which clearly
> > demonstrates that the Android approach to this problem is not the only one
> > possible. ?Moreover, the kernel's system suspend (or hibernate for that matter)
> > code has not been designed to be started from within the kernel. ?It's been
> > designed to allow a privileged user space process to request the kernel to
> > put the system into a sleep state at any given time regardless of what the
> > other user space processes are doing. ?While it can be started from within the
> > kernel, this isn't particularly nice and, in the Android case, starting it from
> > within the kernel requires permission from multiple user space processes
> > (given by not taking suspend blockers these processes are allowed to use).
> >
>
> Why is starting suspend from within the kernel not nice? Personally I
> think reentering suspend from within the kernel is nicer than being
> forced to wake up a user space thread for events that are fully
> handled within the kernel (for instance the battery monitor on the
> Nexus One).
For events that are fully handled within the kernel -- like battery
monitor on Zaurus/spitz -- doing wakeup all the way to the userspace
is not neccessary. But that's implementenation detail with no impact
on user/kernel interface, and we are doing that today. (Or were doing
that few releases ago; charging is broken on spitz just now).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Aug 14, 2010 at 09:38:44AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > Think in terms of an ARM laptop. What good is opportunistic suspend if
> > > > > it's not going to help when the laptop is being used?
> > > >
> > > > For when the laptop is not being used, presumably.
> > >
> > > Or in time between keystrokes for most of the platform (backlight
> > > excepted). The Intel MID x86 devices are at the point that suspend/resume
> > > time on x86 is being hurt by the kernel rewriting smp alternatives as we
> > > go from 2 processors live to 1 and back.
> >
> > Given that you are talking about going from 2 processors to 1 and back,
> > I would guess that you are not actually talking about suspend/resume,
> > which is a system-wide thing rather than a CPU-by-CPU thing. I am not
> > sure whether you are using CPU hotplug or invoking SMP alternatives once
> > all but one CPU is idle.
>
> When entering system suspend, we disable non-boot-CPUs to simplify
> locking. We reenable them when going out of suspend.
Thank you for the info, Pavel!
So once you are down to one CPU, the last CPU shuts the system off,
itself included? Or does the last CPU "run" in a deep idle state
throughout suspend? (My guess is the former, and I am also curious
whether the cache SRAMs are powered off, etc. But figured I should ask
rather than guessing.)
Thanx, Paul
On Sat, 14 Aug 2010 08:10:48 -0700
"Paul E. McKenney" <[email protected]> wrote:
>
> So once you are down to one CPU, the last CPU shuts the system off,
> itself included? Or does the last CPU "run" in a deep idle state
> throughout suspend? (My guess is the former, and I am also curious
> whether the cache SRAMs are powered off, etc. But figured I should
> ask rather than guessing.)
they tend to go "off".
however I think you're making an assumption that there is a
real difference between a deep idle state and "off"....
For modern x86 hardware, that assumption isn't really valid.
(other than a very very small sram that stores register content in the
idle case)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
--- On Sat, 8/14/10, Arjan van de Ven <[email protected]> wrote:
> however I think you're making an assumption
> that there is a real difference between a deep idle state and "off"....
>
> For modern x86 hardware, that assumption isn't
> really valid.
For ARM processors it's not unrealistic. THey
tend to have idle states that place constraints on
peripherals and clocks which allow peripherals to run independently of CPUs.
I recall for example various processors that allow
USB to continue operating in one or more idle states, if the right clocks are active (and RAM).
Similarly with some other peripherals. It may be
desirable to have I/O active while CPUs are idle.
Not all low power states map to x86/ACPI models;
and Linux hasn't accomodated that reality well.
On Sat, Aug 14, 2010 at 09:53:51AM -0700, Arjan van de Ven wrote:
> On Sat, 14 Aug 2010 08:10:48 -0700
> "Paul E. McKenney" <[email protected]> wrote:
> >
> > So once you are down to one CPU, the last CPU shuts the system off,
> > itself included? Or does the last CPU "run" in a deep idle state
> > throughout suspend? (My guess is the former, and I am also curious
> > whether the cache SRAMs are powered off, etc. But figured I should
> > ask rather than guessing.)
>
> they tend to go "off".
>
> however I think you're making an assumption that there is a
> real difference between a deep idle state and "off"....
>
> For modern x86 hardware, that assumption isn't really valid.
> (other than a very very small sram that stores register content in the
> idle case)
I am and have been taking you at your word that some systems can reach
power levels while idle that rival suspended/off. The differences between
idle and suspend are instead semantic, have been posted here more than
once, and make themselves felt when the non-suspended system is non-idle,
even for systems whose deep-idle power approximates that of suspend/off.
Thanx, Paul
On Sam, 2010-08-14 at 09:50 +0200, Pavel Machek wrote:
> On Thu 2010-08-12 08:52:49, Ted Ts'o wrote:
> > On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
> > >
> > > The question is why are we adding a user-space API that:
> > > 1) no user-space beside Android has expresses interest in implementing
> > > 2) is dubious whether the benefits are worth the pain for non-Android
> > > user-space
> > > 3) will become less and less attractive as dynamic PM gets closer to
> > > the sweet-spot, and then surpass it
> > > 4) Android can keep in a separate tree until it's clear in the linux
> > > community that it's useful (if it ever happens)
> >
> > So, Felipe,
> >
> > Do you believe you speak for all of LKML?
[...]
> And yes, for the record Felipe speaks for me pretty well.
Not that I´m as "valuable" as the others quoted above: I have the same
impression.
> Normal path of merging stuff to the kernel is
>
> "Google develops it, then modifies it to address the review comments,
> then it is merged, then it is deployed".
>
> Unfortunately what Google did here is:
>
> "Google develops it behind the closed door, then deploys it. When
> asked for changes, Google expects someone else to create system
> compatible with their existing solution, or else their patches being
> merged."
That basically sums it up as far as I see.
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Sat, 14 Aug 2010 09:50:00 +0200
Pavel Machek <[email protected]> wrote:
> On Thu 2010-08-12 08:52:49, Ted Ts'o wrote:
> > On Thu, Aug 12, 2010 at 03:28:01PM +0300, Felipe Contreras wrote:
> > >
> > > The question is why are we adding a user-space API that:
> > > 1) no user-space beside Android has expresses interest in implementing
> > > 2) is dubious whether the benefits are worth the pain for non-Android
> > > user-space
> > > 3) will become less and less attractive as dynamic PM gets closer to
> > > the sweet-spot, and then surpass it
> > > 4) Android can keep in a separate tree until it's clear in the linux
> > > community that it's useful (if it ever happens)
> >
> > So, Felipe,
> >
> > Do you believe you speak for all of LKML?
> >
> > Are you willing to tell ZDNet and the Slashdot fanboys that it's OK
> > for Suspend blockers to live in a separate tree, and it's not a case
> > of OMG! Google is forking the kernel?
> >
> > If you could speak out a passionately on those forums as you have
> > here, that would be great.
>
> Ted, what is going on here? Are you suggesting people disagreeing with
> Google patches suddenly have to do advocacy for Google?
>
> And yes, for the record Felipe speaks for me pretty well.
>
> Normal path of merging stuff to the kernel is
>
> "Google develops it, then modifies it to address the review comments,
> then it is merged, then it is deployed".
Pavel, you should know better than this. You've been working on Linux
long enough to know that development doesn't happen this way.
It's far more common (and prudent, business-wise) for companies to
develop changes against upstream Linux, ship them, and then try to get
them or something like them integrated upstream. This often works
fine, but big problems arise when either the company in question
doesn't bother to ever push upstream (Linux loses out on support for a
given feature or hardware) or ships changes that have very little
chance of getting upstream (we end up with a fork).
> Unfortunately what Google did here is:
>
> "Google develops it behind the closed door, then deploys it. When
> asked for changes, Google expects someone else to create system
> compatible with their existing solution, or else their patches being
> merged."
Although it would have been nice for Google to work more directly with
upstream on their suspend blockers for Android, I don't think they
could have made their product development cycle a slave to the politics
of upstream development.
Fortunately in this case the problem doesn't seem to be fatal. We've
already established that the userland API portion of suspend blockers
could be implemented in userspace with a bit more work, given that the
kernel problems with suspend/resume and events are addressed.
Hopefully Google is already developing a prototype userspace
implementation to make sure it's workable; being able to build stock
upstream kernels for my Droid and its Android userspace sure would be
nice.
--
Jesse Barnes, Intel Open Source Technology Center
On Sat, Aug 14, 2010 at 09:53:51AM -0700, Arjan van de Ven wrote:
> they tend to go "off".
>
> however I think you're making an assumption that there is a
> real difference between a deep idle state and "off"....
>
> For modern x86 hardware, that assumption isn't really valid.
> (other than a very very small sram that stores register content in the
> idle case)
Really? I thought the TSC stopped in suspend. Does having a package go
into C6 mean that the RAM goes into self-refresh?
--
Matthew Garrett | [email protected]
On Saturday, August 14, 2010, James Bottomley wrote:
> On Fri, 2010-08-13 at 15:08 -0400, Ted Ts'o wrote:
> > On Fri, Aug 13, 2010 at 01:11:29PM -0400, James Bottomley wrote:
> > >
> > > The facts are that suspend blockers identifies a race within our suspend
> > > to ram system that permeates from top to bottom (that's from server to
> > > mobile). The problem is that resume events are racy with respect to
> > > suspend and vice versa. This manifests itself most annoyingly on my
> > > laptop in the "double suspend" case: where I suspend with a pending
> > > suspend event, my laptop will resume and then immediately re-suspend
> > > (leading me to kick myself and remind myself to check it stayed up
> > > before pushing unsuspend and walking away). The other annoying case is
> > > that if I accidentally close the lid before presenting, I have to wait
> > > until the system is fully down before pressing resume.
> >
> > This is all true, but it's also only one aspect of the problem. I
> > agree with you that this is the part of the problem which affects
> > Linux at all scales, from Cloud servers in a data center that want to
> > suspend themselves when there's no work to do (and then fail to
> > respond to the WOL packet) to mobile platforms that are suspending
> > much more frequently.
> >
> > However, it doesn't follow that this is the _only_ problem that the
> > Android folks might be interested in solving. Opportunistic suspend
> > is a different part of the problem space, which is generally believed
> > by the Android developers as being far more efficient than a
> > user-space suspend manager. Rafael has stated his complete
> > unwillingness to deal with this part of the problem. OK, so that
> > probably means that for Android, it will have to be an out-of-tree
> > kernel patch.
>
> OK, so I tried desperately to avoid the question of whether
> opportunistic suspend is a good way of managing power. However, it
> seems to me that it is in use by several systems (android, olpc, etc).
> I'll defer the question of whether it's better in user space or kernel
> space to Rafael's investigations ... but I will point out that the
> kernel space patch, once the suspend blockers issue is taken care of
> looks like a single patch to one file, so should be locally containable
> and should allow upstream to be useful as the driver base again.
>
> > The question, then, is whether a solution which addresses the only
> > part of the problem which Rafael is interested in dealing with at this
> > point, is sufficient such that (a) the kernel-level opportunistic
> > suspend can be done as an out-of-tree patch, while simultaneously (b)
> > allowing device drivers for Android devices can utilize Rafael's
> > interfaces to solve the race design bug currently found in our suspend
> > subsystem, while (c) requiring minimal changes to the Android
> > userspace, and (d) providing all of the statistics and debugging
> > functionality required by the Android userspace.
> >
> > If we can engineer a solution which meets (a), (b), (c), and (d)
> > above, then everyone will be happy.
>
> That's my goal.
In fact, we (which means basically Alan Stern and me at this point) are working
with Arve on this right now.
Thanks,
Rafael
On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote:
> Fortunately in this case the problem doesn't seem to be fatal. We've
> already established that the userland API portion of suspend blockers
> could be implemented in userspace with a bit more work, given that the
> kernel problems with suspend/resume and events are addressed.
> Hopefully Google is already developing a prototype userspace
> implementation to make sure it's workable; being able to build stock
> upstream kernels for my Droid and its Android userspace sure would be
> nice.
You know, you don't have to wait for the Android engineers to do this
work. You (or others who want to be able to use stock upstream kernel
with Android devices) could just as easily try to do the "bit more
work" yourselves --- that is, do the open souce thing and scratch
one's own itch.
After all, Rafael is saying he's refusing to accept patches (or
implement) in-kernel oppunsitic suspend for upstream unless it's
proven to him that a userspace implementation isn't sufficient. It
might be just as fair for the Android userspace upstream to refuse to
accept (or engineer) userspace changes unless it is proven that the
userspace version of opporunistic suspend is just as good as the
in-kernel version which is successfully been deployed in millions and
millions of shipping units today...
Speaking personally, it's not clear to me how waking up a userspace
suspend daemon and waiting for it to get scheduled will result in
better power savings than simply handling it in the kernel, but as
soon as someone is willing to do the work, we can find out for sure
who is right.
- Ted
On Mon, 16 Aug 2010 20:20:32 -0400
Ted Ts'o <[email protected]> wrote:
> On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote:
> > Fortunately in this case the problem doesn't seem to be fatal. We've
> > already established that the userland API portion of suspend blockers
> > could be implemented in userspace with a bit more work, given that the
> > kernel problems with suspend/resume and events are addressed.
> > Hopefully Google is already developing a prototype userspace
> > implementation to make sure it's workable; being able to build stock
> > upstream kernels for my Droid and its Android userspace sure would be
> > nice.
>
> You know, you don't have to wait for the Android engineers to do this
> work. You (or others who want to be able to use stock upstream kernel
> with Android devices) could just as easily try to do the "bit more
> work" yourselves --- that is, do the open souce thing and scratch
> one's own itch.
Sure, I could. And the Google guys could put together a whole Debian
distro with suspend blockers sprinkled throughout various apps. But
for my part, I can't justify that kind of work at the moment. Of
course I'd be happy if someone could and did do the work, it would be a
useful exercise and potentially allow Android to work well on stock
kernels.
> After all, Rafael is saying he's refusing to accept patches (or
> implement) in-kernel oppunsitic suspend for upstream unless it's
> proven to him that a userspace implementation isn't sufficient. It
> might be just as fair for the Android userspace upstream to refuse to
> accept (or engineer) userspace changes unless it is proven that the
> userspace version of opporunistic suspend is just as good as the
> in-kernel version which is successfully been deployed in millions and
> millions of shipping units today...
>
> Speaking personally, it's not clear to me how waking up a userspace
> suspend daemon and waiting for it to get scheduled will result in
> better power savings than simply handling it in the kernel, but as
> soon as someone is willing to do the work, we can find out for sure
> who is right.
Yeah it would add some overhead, since suspend blocker calls would use
IPC to a userspace daemon, which would also be responsible for
(periodically?) waking up to see if the system ought to be
suspended... I agree coding it up would be a useful exercise.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 16 Aug 2010 20:20:32 -0400
Ted Ts'o <[email protected]> wrote:
> On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote:
> > Fortunately in this case the problem doesn't seem to be fatal. We've
> > already established that the userland API portion of suspend blockers
> > could be implemented in userspace with a bit more work, given that the
> > kernel problems with suspend/resume and events are addressed.
> > Hopefully Google is already developing a prototype userspace
> > implementation to make sure it's workable; being able to build stock
> > upstream kernels for my Droid and its Android userspace sure would be
> > nice.
>
> You know, you don't have to wait for the Android engineers to do this
> work. You (or others who want to be able to use stock upstream kernel
> with Android devices) could just as easily try to do the "bit more
> work" yourselves --- that is, do the open souce thing and scratch
> one's own itch.
>
> After all, Rafael is saying he's refusing to accept patches (or
> implement) in-kernel oppunsitic suspend for upstream unless it's
> proven to him that a userspace implementation isn't sufficient. It
> might be just as fair for the Android userspace upstream to refuse to
> accept (or engineer) userspace changes unless it is proven that the
> userspace version of opporunistic suspend is just as good as the
> in-kernel version which is successfully been deployed in millions and
> millions of shipping units today...
Reminds me of the one of the first questions asked in a murder investigation
(or so they say on TV)
Cui Bono??
Who benefits? Does Android benefit more by being able to use a standard
kernel, or does Linux benefit more by being able to run Android without
modification.
Currently it seems that only the lawyers^Wpeople who like arguing on lkml are
gaining anything.
Maybe this is the first real fork of Linux - google might be rich enough to
persist with it.
>
> Speaking personally, it's not clear to me how waking up a userspace
> suspend daemon and waiting for it to get scheduled will result in
> better power savings than simply handling it in the kernel, but as
> soon as someone is willing to do the work, we can find out for sure
> who is right.
I'm surprised at this comment Ted!
Power saving is not the single supreme goal, yet you make it sound like it is.
It should be no surprise to anyone if the most maintainable solution uses a
little more power than the most highly optimised solution. I think most of
us would still prefer the more maintainable solution. However, if google
sees a market opportunity for the minor optimisation of suspend-from-kernel
rather than suspend-from-user-space, then it would seem they are welcome to
it.
NeilBrown
Hi,
On Mon, 2010-08-16 at 23:11 +0200, ext Rafael J. Wysocki wrote:
> On Saturday, August 14, 2010, James Bottomley wrote:
<snip>
> > > The question, then, is whether a solution which addresses the only
> > > part of the problem which Rafael is interested in dealing with at this
> > > point, is sufficient such that (a) the kernel-level opportunistic
> > > suspend can be done as an out-of-tree patch, while simultaneously (b)
> > > allowing device drivers for Android devices can utilize Rafael's
> > > interfaces to solve the race design bug currently found in our suspend
> > > subsystem, while (c) requiring minimal changes to the Android
> > > userspace, and (d) providing all of the statistics and debugging
> > > functionality required by the Android userspace.
> > >
> > > If we can engineer a solution which meets (a), (b), (c), and (d)
> > > above, then everyone will be happy.
> >
> > That's my goal.
>
> In fact, we (which means basically Alan Stern and me at this point) are working
> with Arve on this right now.
At least for (d) we - Nokia - would be also interested as well to
contribute, see [1].
In general it should help with keeping the solution more generic.
cheers, igor
[1]
https://lists.linux-foundation.org/pipermail/linux-pm/2010-August/028248.html
On Friday, August 13, 2010, Jesse Barnes wrote:
> On Fri, 13 Aug 2010 05:28:21 +0200
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > On Thursday, August 12, 2010, Jesse Barnes wrote:
> > > On Thu, 12 Aug 2010 12:19:34 -0700
> > > Brian Swetland <[email protected]> wrote:
> > > > Question though -- has every feature ever added to the kernel been a
> > > > feature that there's pre-existing usage of? Seems like a chicken and
> > > > egg problem. Also, some people seem to think there's value in being
> > > > able to build kernels "out of the box" that work with the Android
> > > > userspace -- given that there are a few devices out there that have
> > > > that userspace on 'em.
> > >
> > > We generally try to merge new features like this along with code that
> > > uses said feature, but there are always exceptions. We've merged code
> > > one release or more before the new code gets used for example, which is
> > > fine IMO. What we don't want to see is some new drop of code added and
> > > abandoned, but you already knew that.
> > >
> > > At any rate, if Felipe is the only one arguing against including
> > > suspend blockers in the kernel, you're probably in good shape. Based
> > > on my (rather cursory I admit) evaluation of this thread, it seems like
> > > reasonable people agree that there's a place for a suspend blocker like
> > > API in the kernel, and that dynamic power management is also highly
> > > desirable. So where's the git pull request already? :)
> >
> > In fact my patch going in that direction has been merged already and that
> > code will likely be extended to cover some needs and cases I didn't have in
> > mind when I was preparing it.
>
> Yeah, I like what you've done with dynamic power management, really
> good stuff (the approach is very similar to the one I used for vblank
> interrupt management in the drm layer).
>
> Ted's point about providing the user with a way of knowing which apps
> are blocking things is a good one though, and doesn't seem too hard to
> add. It might even be possible to do it largely with scripts wrapping
> fuser and such.
>
> > However, having discussed the whole issue for many times and reconsidered it
> > thoroughly, I think that it's inappropriate to identify the suspend blockers
> > (or wakelocks) framework with the opportunistic suspend feature as proposed in
> > the original submission of the "suspend blockers" patchset. IMO they really
> > are not the same thing and while the suspend blockers framework is used by
> > Android to implement opportunistic suspend, I don't really believe this is the
> > right approach.
> >
> > We really need something similar to suspend blockers to avoid races between
> > a suspend process and wakeup events, but it isn't necessary to provide user
> > space with an interface allowing it to use these things directly. Such an
> > interface is only necessary in the specific implementation in which the system
> > is suspended as soon as the number of "active" suspend blockers goes down to
> > zero. Arguably, though, this isn't the only possible way to implement a
> > mechanism allowing the system to be suspended automatically when it appears
> > to be inactive.
> >
> > Namely, one can use a user space power manager for this purpose and actually
> > the OLPC project has been doing that successfully for some time, which clearly
> > demonstrates that the Android approach to this problem is not the only one
> > possible. Moreover, the kernel's system suspend (or hibernate for that matter)
> > code has not been designed to be started from within the kernel. It's been
> > designed to allow a privileged user space process to request the kernel to
> > put the system into a sleep state at any given time regardless of what the
> > other user space processes are doing. While it can be started from within the
> > kernel, this isn't particularly nice and, in the Android case, starting it from
> > within the kernel requires permission from multiple user space processes
> > (given by not taking suspend blockers these processes are allowed to use).
>
> Yes, I see your point. But I actually think this is a fairly minor
> distinction. In one case, a privileged app decides when to suspend the
> system, in the other case, one or more of several privileged apps
> decide when a suspend should not be allowed to occur. It's just a
> matter of where you want to put the code and where you want the
> complexity.
Well, that used to be my opinion before the whole discussion started, but
now I think there's more to it.
First off, we need the "forced" suspend, initiated by writing to
/sys/power/state, to work regardless of the "opportunistic" one. Now, the
races between wakeup events and suspend process are also a problem for the
"forced" suspend mechanism, so the fix should not be specific to
"opportunistic" suspend. One could argue that that can be fixed by using
wakelocks as proposed by the Android developers, but this is not the case,
because there's no way to disinguish wakelocks taken by applications (that we
don't want the "forced" suspend to react to) from the wakelocks taken by the
kernel (that are strictly related to "real" wakeup events).
Second, system suspend is really an intrusive operation that does violent
things to many kernel subsystems (it freezes tasks, it puts the mm subsystem
into a degraded mode, it forcibly offlines non-boot CPUs and so on). If that
is to be started from the kernel, the kernel thread starting it should really
ask all of these subsystems if they are OK with whatever it wants to do and the
answer would always be "no" in the majority of cases. The very purpose of that
design is to allow a user to suspend the system whenever he wants and not
to do that when there's an opportunity to power down things because they
appear to be inactive (that may or may not be one of the "whenever the user
wants" situations, but really the user should be able to specify the
conditions). The powering down of things by the kernel when there's an
opportunity should really be done in a more intelligent way (simply becasue the
kernel is potentially able to do that more intelligently).
Finally, in the kernel-driven opportunistic suspend scenario (using wakelocks)
it is not particularly clear which applications should be given the priviledge
to participate in the suspend blocking mechanism. I don't think there are any
criteria which can be universally used for selecting these applications and in
fact on Android that doesn't work very well either (for example, if you leave
Google Maps in the foreground while the screan is off on Nexus One and you
happen to move reasonably quickly from one location to another, it will drain
the battery for the GPS updates much quickier than you'd expect). For this
reason I don't think it is particularly smart to rely on applications when
deciding whether or not to start system suspend. Other criteria should also
be taken into account in general and I have no idea how to provide the kernel
with an interface allowing it to do that. Therefore I don't think the kernel
should start system suspend automatically.
> In general, we try to keep such complexity out of the
> kernel, but not always; there are compelling cases for putting
> complexity in the kernel to provide uniformity and flexibility (e.g.
> application state save/restore vs. system-wide checkpoints, the former
> preserves the "if it can be done outside the kernel, it should be",
> while the latter provides much greater flexibility and avoids the need
> to port applications to potentially incompatible or unportable state
> saves/restore libraries).
I understand that and IMO it should be decided on the case-by-case basis.
In this particular case, however, I don't think it's appropriate to use the
interface designed with user space in mind for implementing a kernel-based
mechanism.
Thanks,
Rafael
On Tue, 17 Aug 2010, Rafael J. Wysocki wrote:
> > In general, we try to keep such complexity out of the
> > kernel, but not always; there are compelling cases for putting
> > complexity in the kernel to provide uniformity and flexibility (e.g.
> > application state save/restore vs. system-wide checkpoints, the former
> > preserves the "if it can be done outside the kernel, it should be",
> > while the latter provides much greater flexibility and avoids the need
> > to port applications to potentially incompatible or unportable state
> > saves/restore libraries).
>
> I understand that and IMO it should be decided on the case-by-case basis.
> In this particular case, however, I don't think it's appropriate to use the
> interface designed with user space in mind for implementing a kernel-based
> mechanism.
Putting the "opportunistic suspend" loop into the kernel doesn't save
as much as one might think. The loop itself is quite simple, and the
task switch it entails is required in any case (since suspend must be
carried out within a process context). Putting it in the kernel would
save a few user/kernel context switches, not enough to matter IMO. And
it wouldn't offer any greater flexibility -- it might even cut down the
flexibility.
Alan Stern
On Sat, Aug 14, 2010 at 09:53:51AM -0700, Arjan van de Ven wrote:
> however I think you're making an assumption that there is a
> real difference between a deep idle state and "off"....
>
> For modern x86 hardware, that assumption isn't really valid.
> (other than a very very small sram that stores register content in the
> idle case)
This is more of CPU statement than a chipset or laptop/device-wide
statement, correct?
If "hardware" applies to the entire laptop, how "modern" is "modern"?
- Ted
On Tue, Aug 17, 2010 at 05:08:58PM +1000, Neil Brown wrote:
>
> Maybe this is the first real fork of Linux - google might be rich enough to
> persist with it.
Define "real fork"? Both SuSE and Red Hat have carried patches, in
some cases for years, forward porting them to newer kernels. Does
that make them forks?
SuSE has made changes to e2fsprogs, and carried those patches for
years and years, and even added options to command-line programs which
SLES's init scripts are dependent on --- and this was done without
even consulting me first. Yet you don't see me calling out SLES for
"forking" e2fsprogs and how it "got away" with it.
Can we please cut out this whole forking nonsense? I've been told
that it's only something Slashdot kiddies and ZDNet media types
looking for advertising impressions. Yet you're a kernel programmer,
and one who works for a distribution, and you've made this same claim;
you should know better.
> I'm surprised at this comment Ted!
> Power saving is not the single supreme goal, yet you make it sound like
> it is.
>
> It should be no surprise to anyone if the most maintainable solution uses a
> little more power than the most highly optimised solution. I think most of
> us would still prefer the more maintainable solution.
I think part of the problem here is what's considered "acceptable" to
one set of developers may not be considered "acceptable" to another
set. As I've said many times before, what makes sense for a cell
phone battery and highly power-optimized hardware may not make sense
for a devices with 6-cell laptop battery. And I think it's still to
be seen whether or not suspend-from-userspace really is as minor as
people think it is, and what compromises might have to be made in how
app programs are forced to develop their applications, etc.
- Ted
On Tue, Aug 17, 2010 at 05:08:58PM +1000, Neil Brown wrote:
> On Mon, 16 Aug 2010 20:20:32 -0400
> Ted Ts'o <[email protected]> wrote:
>
> > On Mon, Aug 16, 2010 at 08:16:55AM -0700, Jesse Barnes wrote:
> > > Fortunately in this case the problem doesn't seem to be fatal. We've
> > > already established that the userland API portion of suspend blockers
> > > could be implemented in userspace with a bit more work, given that the
> > > kernel problems with suspend/resume and events are addressed.
> > > Hopefully Google is already developing a prototype userspace
> > > implementation to make sure it's workable; being able to build stock
> > > upstream kernels for my Droid and its Android userspace sure would be
> > > nice.
> >
> > You know, you don't have to wait for the Android engineers to do this
> > work. You (or others who want to be able to use stock upstream kernel
> > with Android devices) could just as easily try to do the "bit more
> > work" yourselves --- that is, do the open souce thing and scratch
> > one's own itch.
> >
> > After all, Rafael is saying he's refusing to accept patches (or
> > implement) in-kernel oppunsitic suspend for upstream unless it's
> > proven to him that a userspace implementation isn't sufficient. It
> > might be just as fair for the Android userspace upstream to refuse to
> > accept (or engineer) userspace changes unless it is proven that the
> > userspace version of opporunistic suspend is just as good as the
> > in-kernel version which is successfully been deployed in millions and
> > millions of shipping units today...
>
> Reminds me of the one of the first questions asked in a murder investigation
> (or so they say on TV)
> Cui Bono??
>
> Who benefits? Does Android benefit more by being able to use a standard
> kernel, or does Linux benefit more by being able to run Android without
> modification.
>
> Currently it seems that only the lawyers^Wpeople who like arguing on lkml are
> gaining anything.
>
> Maybe this is the first real fork of Linux - google might be rich enough to
> persist with it.
>
> > Speaking personally, it's not clear to me how waking up a userspace
> > suspend daemon and waiting for it to get scheduled will result in
> > better power savings than simply handling it in the kernel, but as
> > soon as someone is willing to do the work, we can find out for sure
> > who is right.
>
> I'm surprised at this comment Ted!
> Power saving is not the single supreme goal, yet you make it sound like it is.
My initial impression was also that power savings was Android's single
supreme goal, but a careful reading of this thread and the ones preceding
it taught me otherwise. Please see below for my current understanding
of what they are trying to accomplish. As always, feedback is welcome!
Thanx, Paul
------------------------------------------------------------------------
Subject: Attempted summary of suspend-blockers LKML thread, epilogue 1
Final report from this particular angel-free zone for the time being...
This is the third^Wfourth and final version of my Android requirements
list (last version available at http://lkml.org/lkml/2010/8/6/581).
Again, this email is an attempt to present the Android guys' requirements,
based on my interpretation of LKML discussions. Thank you to everyone
who took part.
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 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 our collective understanding of what the Android
folks' requirements are. That said, I do discuss example mechanisms
where needed to clarify the meaning of the requirements. This should
not be interpreted as a preference for any given example mechanism.
Thanx, Paul
------------------------------------------------------------------------
CONTENTS
o DEFINITIONS
o CATEGORIES OF APPLICATION BEHAVIOR
o REQUIREMENTS
o NICE-TO-HAVES
o APPARENT NON-REQUIREMENTS
o SUGGESTED USAGE
o POWER-OPTIMIZED APPLICATIONS
o OTHER EXAMPLE APPLICATIONS
o ACKNOWLEDGMENTS
DEFINITIONS
These have been updated based on LKML and linux-pm discussions. The names
are probably still sub-optimal, but incremental progress is nevertheless
a very good thing.
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
externally powered PCs. Many other people seemed to instead be
thinking in terms of an ill-conceived or useless application,
perhaps exemplified by "bouncing cows".
This document uses "power-oblivious applications" to mean
applications that are well-designed and well-implemented in in
general, but which do not take power consumption or battery life
into account.
o "PM-driving 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 processes are classified as power aware. Android uses a
user-level daemon to classify app-store apps as PM-driving or not.
More generally, PM-driving applications are those that have
permission to exert some control over the system's sleep state.
Note that an application might be power-oblivious on one
Android device and PM-driving on another, depending on whether
the user allows that application to acquire suspend blockers.
The classification might even change over time. For example,
a user might give an application PM-driving status initially,
but change his or her mind after some experience with that
application.
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
PM-driving applications that have been aggressively tuned to
reduce power consumption.
o Individual devices in an embedded system can enter "device
low-power states" when not in use.
o The system as a whole can enter a "system sleep state" when
the system as a whole is not in use. Suspend blockers are about
system sleep states rather than device low-power states.
o There was much discussion of "idle" (AKA "deep idle") and
"suspend" (as in current Linux-kernel suspend operations).
The following characteristics distinguish "idle" from "suspend":
1. Idle states are entered by a given CPU only there are no
runnable tasks for that CPU. In contrast, opportunistic
suspend can halt the entire system even when there
are tasks that are ready, willing, and able to run.
(But please note that this might not apply to real-time
tasks.)
Freezing of subsets of applications is somewhat related
to the idle/suspend discussion, but is covered in a
later section of this document.
2. There can be a set of input events that do not bring
the system out of suspend, but which would bring the
system out of idle. Exactly which events are in this
set depends both on hardware capabilities and on the
platform/application policy. For example, on one of
the Android-based smartphones, touchscreen input is
ignored when the system is suspended, but is handled
when idle.
3. The system comes out of idle when a timer expires. In
contrast, timers might or might not bring the system
out of suspend, depending on both hardware capabilities
and platform/application policy.
4. Suspend generally forces devices to go into their
low-power states immediately. In contrast, idle generally
leaves unused devices at full power, relying on timers
to shut down these devices. Idle thus often has shorter
average wakeup latencies, but on systems where suspend
can use deeper sleep states than can idle, idle might
have worse energy efficiency.
5. Suspend shuts down timekeeping, but deep idle currently
does not. Timekeeping requires periodic interrupts to
correctly compute time. If these interrupts are spaced
too far apart (for example, by minutes or hours),
timekeeping can become inaccurate. The degree of
inaccuracy and the permissible spacing intervals depends
on the time-source hardware and the kernel configuration.
(It might be possible to reduce the timekeeping system's
dependency on periodic interrupts, but this is currently
speculation rather than reality.)
6. Suspend usually has longer wakeup latency than does
idle.
CATEGORIES OF APPLICATION BEHAVIOR
There are a number of categories of application behavior with respect
to power management and energy efficiency. These can be classified via
the following questions: (1) What degree of control is an application
permitted over its own behavior? (2) What degree of control is an
application permitted over the power state of individual devices within
the system? (3) What degree of control is an application permitted
over the system sleep state? (4) To what degree has the application
been tuned to reduce its power consumption, either in isolation or in
conjunction with other applications that might be running concurrently?
These categories are discussed below.
o What degree of control is an application permitted over its
own behavior?
The Linux kernel already has many controls over application
behavior:
o the CAP_ capabilities from include/linux/capability.h.
o Processes can be assigned to multiple groups, allowing
them privileged access to portions of the filesystem.
o The chroot() system call limits a process's access to the
specified subtree of the filesystem.
o The ulimit facility can limit CPU consumption, number
of processes, memory, etc. on a per-user basis. The
rlimit facility has similar effects on a per-process
basis.
o The mlockall() system call provides privileged access
to memory, avoiding page-fault overhead.
But more relevant to this discussion, real-time processes are
permitted a much higher degree of control over the timing of their
execution than are non-real-time processes. However, suspending
the system destroys any pretense of offering real-time guarantees,
which might explain much of the annoyance towards suspend blockers
from the real-time and scheduler folks. For but one example,
Peter Zijlstra suggested that he would merge a patch that acquired
a suspend blocker any time that the runqueues were non-empty.
My first reaction was amusement at this vintage Peter Zijlstra
response, and my second reaction was that it was a futile gesture,
as the Android guys would simply back out any such change.
After more thought, however, a variation of Peter's approach
might well be the key to resolving this tension between
real-time response on the one hand and Android's desire to
conserve power at any cost on the other. Given that suspending
destroys real-time response, why not acquire a suspend blocker
any time there is a user-created real-time task in the system,
whether runnable or not? Of course, a simpler approach would
be to make Android's OPPORTUNISTIC_SUSPEND depend on !PREEMPT_RT.
o What degree of control is an application permitted over the power
state of individual devices within the system?
Is the application in question permitted to power down the
CPU or peripheral devices? As more of the power control is
automated based on usage, it is possible that this question will
become less relevant. The longer the latency and the greater
the energy consumption of a power-up/power-down sequence for
a given device, the less suitable that device is for automatic
power-up/power-down decisions. Cache SRAMs and main-memory
DRAM tend to be less suitable for automation for this reason.
o What degree of control is an application permitted over the
system sleep state?
Is the application permitted to suspend the device? Or in the
case of Android, is the application permitted to acquire a
suspend blocker, which prevents the device from being suspended?
o To what degree has the application been tuned to reduce its
power consumption, either in isolation or in conjunction with
other applications that might be running concurrently?
See the "POWER-OPTIMIZED APPLICATIONS" section below for more
detail on the lengths that embedded developers go to in order
to conserve power -- or, more accurately, to extend battery life.
REQUIREMENTS
o Reduce the system's power consumption in order to (1) extend
battery life and (2) preserve state until external power can
be obtained.
o It is necessary to be able to use power-oblivious 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 external power or
(2) relatively undemanding laptop battery-lifetime expectations.
The system must be capable of running these power-oblivious
applications without requiring that these applications be
modified, and must be capable of reasonable power efficiency
even when power-oblivious applications are in use.
In other words, it must be possible to automate the incorporation
of a power-oblivious application into the Android environment,
but without significantly degrading battery lifetime.
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 it is highly desirable that the
application also be prevented from consuming power computing
something that will not be displayed. Furthermore, whatever
mechanism is used must operate on power-oblivious applications
that do not use blocking system calls.
There might well be similar requirements for other output-only
devices, as noted by Alan Stern.
o In order to avoid overrunning hardware and/or kernel buffers,
and to minimize response latencies, designated 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 sleep state is received while the system is
transitioning into a sleep state, the system must transition
back out of the sleep state so that it can hand the user
input off to the corresponding application.
Other input events do not force a wakeup, and such input events
-can- be lost due to buffer overflow in hardware or the kernel.
The response latency to such input events can of course be
unbounded.
o Because Android acquires a suspend blocker as soon as an
input event is noticed and holds it until some application
reads that input event, there must be a way to cause the
suspend blocker to timeout. If there was no such timeout
facility, a power-oblivious application could block suspend by
opening an input device and then refusing to ever read from it.
(Yes, this can be considered to be a energy-efficiency bug in
the power-oblivious application. Please see the statistics
requirement below.)
o The API must provide a way for PM-driving applications that
receive events to keep themselves running until they have been
able to process those events.
o It must be possible to apply power-oblivious coding techniques
to those code sequences in PM-driving applications where suspend
blockers are not held.
o Statistics of the power-control actions taken by PM-driving
applications must be provided. Statistics are aggregated by name,
which is passed by the application in through the suspend-blocker
interface. The following specific statistics are collected in
the kernel, in roughly decreasing order of importance:
o total_time, which accumulates the total amount of time
that the corresponding suspend blocker has been held.
o active_since, which tracks how long a suspend blocker has
been held since it was last acquired, or (presumably) zero
if it is not currently held.
o count, which is the number of times that the suspend
blocker has been acquired. This is useful in combination
with total_time, as it allows you to calculate the
average hold time for the suspend blocker.
o expire_count, which is the number of times that the
suspend blocker has timed out. This indicates that
some application has an input device open, but is
not reading from it, which is a bug, as noted earlier.
o max_time, which is the longest hold time for the suspend
blocker. This allows finding cases where suspend blockers
are held for too long, but are eventually released.
(In contrast, active_since is more useful in the
held-forever case.)
o sleep_time, which is the total time that the suspend
blocker was held while the display was powered off.
(This might have interesting implications should E-ink
displays every become capable of full-motion color video,
but it is easy to imagine that the definition of "powered
off" would then include only those times during which
the display wasn't actively being updated.)
o wake_count, which is the number of times that the
suspend blocker was the first to be acquired in the
resume path. This is less than useful on some
Android platforms; Arve is dissatisfied with it
on Nexus One.
Presumably, the userspace code collects similar statistics on
application suspend-blocker activity, but that is out of the scope
of this document, which focuses instead on kernel requirements.
Given that the overhead of maintaining these statistics is
quite low, it seems that it would be worthwhile to have them
enabled in production systems, for example, in order to flag
power-buggy applications that the user has naively downloaded.
o Some PM-driving applications use power-oblivious infrastructure
code. This means that a PM-driving application must have
some way, whether explicit or implicit, to ensure that any
power-oblivious infrastructure code is permitted to run when a
PM-driving application needs it to run.
o If no PM-driving or power-optimized application are indicating
a need for the system to remain operating, the system is permitted
(even encouraged!) to suspend all execution, regardless of the
state of power-oblivious applications. (This requirement did
appear to be somewhat controversial, both in terms of what is
meant by "runnable" and in terms of what constitutes "execution".)
In Android, this is implemented by suspending even while
PM-driving or power-optimized applications are active, -unless-
a suspend blocker is held.
o Transition to system sleep state must be power-efficient.
In particular, methods based on repeated attempts to suspend
are considered to be too inefficient to be useful.
o Transition to system sleep state must occur very soon after
all PM-driving and power-optimized applications have indicated
that they have no need for the system to remain operating.
Quick transition is expecially important in cases where the wakeup
was momentary, for example, when processing sporadic network
input or processing widely spaced batches of audio output.
For an example of the latter, MP3 playback allows 1-4 minute
spacing between bursts of CPU activity).
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 sleep 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 The API that controls the system sleep 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 sleep 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. According to Brian
Swetland:
For Java/Dalvik apps, the wakelock API is pertty
high level -- it talks to a service via RPC (Binder)
that actually interacts with the kernel. Changing the
basic kernel<->userspace interface (within reason) is
not unthinkable. For example, Arve's suspend_blocker
patch provides a device interface rather than the proc
interface the older wakelock patches use. We'd have to
make some userspace changes to support that but they're
pretty low level and minor.
In the current model, only a few processes need to
specifically interact with the kernel (the power
management service in the system_server, possibly the
media_server and the radio interface glue). A model where
every process needs to have a bunch of instrumentation is
not very desirable from our point of view. We definitely
do need reasonable statistics in order to enable debugging
and to enable reporting to endusers (through the Battery
Usage UI) what's keeping the device awake.
o Any mechanism that freezes some subset of the applications must
ensure that none of the frozen applications hold any user-level
resources, such as pthread mutexes. The reason for this is that
freezing an application that holds a shared pthread mutex will
result in an application-level hang should some unfrozen process
attempt to acquire that same pthread mutex. Note that although
the current cgroup freezer ensures that frozen applications do not
hold any kernel-level mutexes (at least assuming these mutexes
are not wrongly held when returning to user-level execution),
it currently does nothing to prevent freezing processes holding
pthread mutexes. (There are some proposals to address this issue.)
NICE-TO-HAVES
o It would be nice to be able to identify power-oblivious
applications that never were depended on by PM-driving
applications. This particular class of power-oblivious
applications could be shut down when the screen blanks even
if some PM-driving application was preventing the system from
powering down.
There are two obstacles to meeting this requirement:
1. There must be a reliable way to identify such
applications. This should be doable, for example, the
application might be tagged by its developer.
2. There must be a reliable way to freeze them such
that no frozen application holds a resource that
might be contended by a non-frozen application.
Although the cgroup freezer does ensure that frozen
tasks hold no kernel-level resources, it currently does
nothing to ensure that no user-level resources are held.
There are some alternative proposals, which might or
might not be more successful:
a. Unfreeze this group periodically to ensure
that any such resource is eventually released,
while keeping power consumption down to a dull
roar.
b. Perform the freeze at application level, where
it is possible to determine whether an
application-level resource is held.
o Any initialization of the API that controls the system power
state should be unconditional, so as to be free from failure.
Such unconditional initialization reduces the intrusiveness of
the Android patchset.
APPARENT NON-REQUIREMENTS
o Transitioning to system sleep states need not be highly scalable,
as evidenced by the global locks. (If you believe that high
scalability 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.)
That said, it should not be hard to provide a highly scalable
implementation of suspend blockers, especially if large systems
are allowed to take their time suspending themselves.
o Conserving power in the WiFi and cellular telephony networks.
At the moment, the focus is on increased battery life in the
handheld device, perhaps even at the expense of additional
power consumed by the externally powered WiFi and cell-telephony
equipment.
o Synchronizing wakeups of unrelated applications. This is of
course an important requirement for power savings overall, but
seems to be left to other mechanisms (e.g., timer aggregation)
by the Android folks. Although one could implement suspend
blockers so as to aggregate timers after a sufficiently long
suspension, there are problems with this approach:
o There would be a "thundering herd" problem just after
resume completed as almost every timer in the system
would expire simultaneously.
o The applications would not necessarily stay aggregated
without some other mechanism helping out.
SUGGESTED USAGE
These are constraints that the developer is expected to abide by,
"for best results" and all that.
o When a PM-driving application is preventing the system from
shutting down, and is also waiting on a power-oblivious
application, the PM-driving application should set a timeout
to handle the possibility that the power-oblivious application
might halt or otherwise fail.
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 sleep 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 achieve 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. Provide "heartbeat" services that allow applications to
synchronize with each other. This seems most applicable for
applications that run infrequently, such as email-checking and
location-service applications.
5. 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.
6. 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 PM-driving (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-oblivious 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.
ACKNOWLEDGMENTS
Of course, just because I acknowledge their contributions does
not necessarily mean that I think they agree with my assessment
of the requirements behind suspend blockers. ;-)
Nevertheless, I am grateful for any and all feedback, whatever
the form of that feedback might be. I am new to this area, and
have much to learn.
Alan Stern
Anca Emanuel
Arjan van de Ven
Arve Hj?nnev?g
Brian Swetland
David Brownell
David Lang
Florian Mickler
James Bottomley
Kevin Granade
Mark Brown
Matt Helsley
Matthew Garrett
Mikael Abrahamsson
Olivier Galibert
Paul Menage
Pavel Machek
Rafael J. Wysocki
Richard Woodruff
Ted Ts'o
On Fri, 13 Aug 2010, Paul E. McKenney wrote:
> On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
>> On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
>> <[email protected]> wrote:
>>> On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
>>>>> It seems to me that the same social-engineering approaches work in
>>>>> both cases.
>>>>
>>>> Yes, but if dynamic PM works as advertised, you don't need
>>>> opportunistic suspend.
>>>
>>> For dynamic power management to totally eliminate the need for something
>>> like suspend blockers, you are having to make some brave assumptions.
>>> Yes, dynamic power management is quite useful, but there is a big
>>> difference between something being useful and something doing everything
>>> for everyone. ?You have not yet convinced me that dynamic power management
>>> will make it to the "doing everything for everyone" stage.
>>
>> As it has been explained before, there's a sweet-spot of idleness:
>> http://article.gmane.org/gmane.linux.kernel/995525
>> http://article.gmane.org/gmane.linux.ports.arm.omap/37982
>>
>> Do you agree that there's such a thing, and if so, do you agree that
>> the benefits of opportunistic suspend are much less once that point is
>> reached?
>
> I agree that there will be a sweet spot of idleness (though I would call
> it a "point of diminishing returns"), but only if all the applications
> are power-optimized. The advantage of opportunistic suspend is instead
> its tolerance of power-oblivious applications with minimal degradation
> of battery life.
sorry for the late response, the last week has been very hectic.
I just wanted to note that there is already a tool in the kernel to deal
with this, the timer jitter/fuzz control. This can be set by an
application for itself, or it can be set by some other process for an
application (I don't remember the details of all the ways this can be set)
This could be used in a way similar to how userspace wakelocks are set
today, if the power management process (that holds the wakelock and keep
sthe screen lit today) thinks the system should be awake, let the
jitter/fuzz be small, if that process thinks the system should probably be
asleep, set the jitter/fuzz to a larger value. If other things are running
anyway, the timers can fire and be serviced normally, otherwise the kernel
is free to delay the timer going off even for badly written processes.
David Lang
On Thu, Aug 19, 2010 at 04:10:10PM -0700, [email protected] wrote:
> On Fri, 13 Aug 2010, Paul E. McKenney wrote:
>
> >On Thu, Aug 12, 2010 at 08:52:22PM +0300, Felipe Contreras wrote:
> >>On Thu, Aug 12, 2010 at 7:19 PM, Paul E. McKenney
> >><[email protected]> wrote:
> >>>On Thu, Aug 12, 2010 at 03:17:29AM +0300, Felipe Contreras wrote:
> >>>>>It seems to me that the same social-engineering approaches work in
> >>>>>both cases.
> >>>>
> >>>>Yes, but if dynamic PM works as advertised, you don't need
> >>>>opportunistic suspend.
> >>>
> >>>For dynamic power management to totally eliminate the need for something
> >>>like suspend blockers, you are having to make some brave assumptions.
> >>>Yes, dynamic power management is quite useful, but there is a big
> >>>difference between something being useful and something doing everything
> >>>for everyone. ?You have not yet convinced me that dynamic power management
> >>>will make it to the "doing everything for everyone" stage.
> >>
> >>As it has been explained before, there's a sweet-spot of idleness:
> >>http://article.gmane.org/gmane.linux.kernel/995525
> >>http://article.gmane.org/gmane.linux.ports.arm.omap/37982
> >>
> >>Do you agree that there's such a thing, and if so, do you agree that
> >>the benefits of opportunistic suspend are much less once that point is
> >>reached?
> >
> >I agree that there will be a sweet spot of idleness (though I would call
> >it a "point of diminishing returns"), but only if all the applications
> >are power-optimized. The advantage of opportunistic suspend is instead
> >its tolerance of power-oblivious applications with minimal degradation
> >of battery life.
>
> sorry for the late response, the last week has been very hectic.
>
> I just wanted to note that there is already a tool in the kernel to
> deal with this, the timer jitter/fuzz control. This can be set by an
> application for itself, or it can be set by some other process for
> an application (I don't remember the details of all the ways this
> can be set)
>
> This could be used in a way similar to how userspace wakelocks are
> set today, if the power management process (that holds the wakelock
> and keep sthe screen lit today) thinks the system should be awake,
> let the jitter/fuzz be small, if that process thinks the system
> should probably be asleep, set the jitter/fuzz to a larger value. If
> other things are running anyway, the timers can fire and be serviced
> normally, otherwise the kernel is free to delay the timer going off
> even for badly written processes.
Indeed, Rafael and Alan Stern are working to make pm_qos do what the
Android guys need, which could (very roughly) be thought of as extending
the jitter/fuzz such that it meets Android's requirements.
Thanx, Paul
Hi!
> > You are *one* user of the kernel. Let's suppose Android wasn't using
> > suspend-blockers, and there was another equally successful linux
> > mobile platform, Foobingo, and they were using them, and they were the
> > only ones interested on implementing them.
> >
> > What does that change? Nothing. They still need to convince the
> > community that what they are proposing to be merged is actually
> > useful, and somebody will use it. If not, they can just keep the patch
> > for themselves until they do. I don't see the big deal.
>
> So the current users of the Linux kernel are the following?
>
> o GNU/Linux
> o Android
>
> Do any other distributions or devices with unusual user-space layouts
> qualify?
QTembedded distros are somehow similar to android (one big binary).
Then there's minor stuff, like webOS and Motorola A1200...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Aug 28, 2010 at 10:51:35AM +0200, Pavel Machek wrote:
> Hi!
>
> > > You are *one* user of the kernel. Let's suppose Android wasn't using
> > > suspend-blockers, and there was another equally successful linux
> > > mobile platform, Foobingo, and they were using them, and they were the
> > > only ones interested on implementing them.
> > >
> > > What does that change? Nothing. They still need to convince the
> > > community that what they are proposing to be merged is actually
> > > useful, and somebody will use it. If not, they can just keep the patch
> > > for themselves until they do. I don't see the big deal.
> >
> > So the current users of the Linux kernel are the following?
> >
> > o GNU/Linux
> > o Android
> >
> > Do any other distributions or devices with unusual user-space layouts
> > qualify?
>
> QTembedded distros are somehow similar to android (one big binary).
>
> Then there's minor stuff, like webOS and Motorola A1200...
It does sounds like there is some variety, then. Thank you for the info!
Thanx, Paul