Attempted summary of suspend-blockers LKML thread

Quoted 26 lines · Paul E. McKenney

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.

Quoted 3 lines

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.

Quoted 18 lines

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

Quoted 8 lines

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.

Quoted 5 lines

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?

Quoted 4 lines

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

Quoted 10 lines

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.

Quoted 2 lines

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

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 9 lines

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.

Quoted 9 lines

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

Quoted 10 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 14 lines

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

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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

Paul E. McKenney

author

2010-08-01 04:36 UTC #3 lore raw

Quoted 28 lines · Alan Stern

Quoted 26 lines · Paul E. McKenney
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.

Quoted 6 lines

Quoted 3 lines
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!!!

Quoted 27 lines

Quoted 18 lines
------------------------------------------------------------------------
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.
Quoted 8 lines
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.

Quoted 6 lines

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.

Quoted 8 lines

Quoted 5 lines
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.

Quoted 6 lines

Quoted 4 lines
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.

Quoted 10 lines

Quoted 10 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 8 lines

Quoted 5 lines
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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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?

Quoted 4 lines

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?

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 17 lines

Quoted 10 lines
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.
Quoted 6 lines
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.)

Quoted 3 lines

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.

Quoted 9 lines

Quoted 5 lines
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?

Quoted 14 lines

Quoted 14 lines
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).

Quoted 6 lines

Quoted 4 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 8 lines

Quoted 8 lines
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

Paul E. McKenney

author

2010-08-01 04:36 UTC #4 lore raw

Quoted 28 lines · Alan Stern

Quoted 26 lines · Paul E. McKenney
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.

Quoted 6 lines

Quoted 3 lines
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!!!

Quoted 27 lines

Quoted 18 lines
------------------------------------------------------------------------
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.
Quoted 8 lines
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.

Quoted 6 lines

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.

Quoted 8 lines

Quoted 5 lines
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?

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

Quoted 6 lines

Quoted 4 lines
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.

Quoted 10 lines

Quoted 10 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 8 lines

Quoted 5 lines
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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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?

Quoted 4 lines

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?

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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".

Quoted 17 lines

Quoted 10 lines
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.
Quoted 6 lines
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.)

Quoted 3 lines

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.

Quoted 9 lines

Quoted 5 lines
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?

Quoted 14 lines

Quoted 14 lines
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).

Quoted 6 lines

Quoted 4 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 8 lines

Quoted 8 lines
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

Alan Stern

2010-08-01 19:41 UTC #5 lore raw

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
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).

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 10 lines

Quoted 7 lines
Quoted 3 lines
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.

Quoted 11 lines

Quoted 7 lines
Quoted 3 lines
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.

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
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.)

Quoted 8 lines

Quoted 3 lines
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.

Quoted 11 lines

Quoted 9 lines
Quoted 5 lines
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

2010-08-01 19:41 UTC #6 lore raw

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
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).

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

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.

Quoted 10 lines

Quoted 7 lines
Quoted 3 lines
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.

Quoted 11 lines

Quoted 7 lines
Quoted 3 lines
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.

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
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.)

Quoted 8 lines

Quoted 3 lines
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.

Quoted 11 lines

Quoted 9 lines
Quoted 5 lines
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

Paul E. McKenney

author

2010-08-01 20:11 UTC #7 lore raw

Quoted 16 lines · Alan Stern

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 6 lines
Quoted 6 lines
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.

Quoted 5 lines

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?

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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.

Quoted 14 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 8 lines

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?

Quoted 4 lines

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

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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".

Quoted 6 lines

Quoted 3 lines
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.

Quoted 16 lines

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.)
Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

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?

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.)

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
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

Paul E. McKenney

author

2010-08-01 20:11 UTC #8 lore raw

Quoted 16 lines · Alan Stern

Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
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.
Quoted 6 lines
Quoted 6 lines
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.

Quoted 5 lines

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?

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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).

Quoted 14 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 8 lines

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?

Quoted 4 lines

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

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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".

Quoted 6 lines

Quoted 3 lines
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.

Quoted 16 lines

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.)
Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

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?

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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.)

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
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

Alan Stern

2010-08-01 22:16 UTC #9 lore raw

Quoted 7 lines · Paul E. McKenney

Quoted 5 lines
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".

Quoted 9 lines

Quoted 8 lines
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.

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 6 lines
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

2010-08-01 22:16 UTC #10 lore raw

Quoted 7 lines · Paul E. McKenney

Quoted 5 lines
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?

Quoted 9 lines

Quoted 8 lines
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.

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 6 lines
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

David Brownell

2010-08-01 22:38 UTC #11 lore raw

Quoted 3 lines

Quoted 1 line
Quoted 1 line
I should have made a stronger point:
"power-aware" is _not_ a good
Quoted 1 line
Quoted 1 line
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".

David Brownell

2010-08-01 22:38 UTC #12 lore raw

In reply to David Brownell

Quoted 3 lines

Quoted 1 line
Quoted 1 line
I should have made a stronger point:
"power-aware" is _not_ a good
Quoted 1 line
Quoted 1 line
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".

Paul E. McKenney

author

2010-08-02 00:29 UTC #13 lore raw

Quoted 11 lines · David Brownell

Quoted 3 lines
Quoted 1 line
Quoted 1 line
I should have made a stronger point:
"power-aware" is _not_ a good
Quoted 1 line
Quoted 1 line
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

Paul E. McKenney

author

2010-08-02 00:29 UTC #14 lore raw

Quoted 11 lines · David Brownell

Quoted 3 lines
Quoted 1 line
Quoted 1 line
I should have made a stronger point:
"power-aware" is _not_ a good
Quoted 1 line
Quoted 1 line
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".

Thanx, Paul

Paul E. McKenney

author

2010-08-02 00:28 UTC #15 lore raw

Quoted 8 lines · Alan Stern

Quoted 6 lines · Paul E. McKenney
Quoted 5 lines
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.

Quoted 7 lines

Quoted 1 line
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. ;-)

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
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.

Quoted 7 lines

Quoted 5 lines
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!!!

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Paul E. McKenney

author

2010-08-02 00:28 UTC #16 lore raw

Quoted 8 lines · Alan Stern

Quoted 6 lines · Paul E. McKenney
Quoted 5 lines
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.

Quoted 7 lines

Quoted 1 line
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 am of course open to improvements in the "PM-driving applications" name. ;-)

Quoted 9 lines

Quoted 9 lines
Quoted 8 lines
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.

Quoted 7 lines

Quoted 5 lines
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!!!

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Rafael J. Wysocki

2010-08-01 15:41 UTC #17 lore raw

Quoted 28 lines · Alan Stern

Quoted 26 lines · Paul E. McKenney
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.

Quoted 24 lines

Quoted 3 lines
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.
Quoted 17 lines
------------------------------------------------------------------------
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.

Quoted 9 lines

Quoted 8 lines
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.

Quoted 6 lines

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.

Quoted 8 lines

Quoted 5 lines
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".

Quoted 17 lines

Quoted 4 lines
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).
Quoted 10 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 8 lines

Quoted 5 lines
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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 17 lines

Quoted 10 lines
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.
Quoted 6 lines
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.)

Quoted 3 lines

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.

Quoted 9 lines

Quoted 5 lines
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

Rafael J. Wysocki

2010-08-01 15:43 UTC #18 lore raw

Quoted 28 lines · Alan Stern

Quoted 26 lines · Paul E. McKenney
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.

Quoted 24 lines

Quoted 3 lines
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.
Quoted 17 lines
------------------------------------------------------------------------
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.

Quoted 9 lines

Quoted 8 lines
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.

Quoted 6 lines

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.

Quoted 8 lines

Quoted 5 lines
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?

Quoted 17 lines

Quoted 4 lines
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).
Quoted 10 lines
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.

Quoted 6 lines

Quoted 2 lines
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 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.

Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 8 lines

Quoted 5 lines
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.

Quoted 5 lines

Quoted 5 lines
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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 6 lines

Quoted 6 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 17 lines

Quoted 10 lines
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.
Quoted 6 lines
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.)

Quoted 3 lines

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.

Quoted 9 lines

Quoted 5 lines
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

Paul E. McKenney

author

2010-08-01 19:56 UTC #19 lore raw

Quoted 49 lines · Rafael J. Wysocki

Quoted 48 lines · Alan Stern
Quoted 26 lines · Paul E. McKenney
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.
Quoted 3 lines
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.
Quoted 13 lines
------------------------------------------------------------------------
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".

Quoted 8 lines

Quoted 4 lines
Quoted 4 lines
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".

Quoted 16 lines

Quoted 9 lines
Quoted 8 lines
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.
Quoted 6 lines
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.

Quoted 5 lines

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

Quoted 7 lines

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.

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 24 lines

Quoted 17 lines
Quoted 4 lines
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).
Quoted 10 lines
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.
Quoted 6 lines
Quoted 2 lines
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.)

Quoted 6 lines

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.

Quoted 20 lines

Quoted 4 lines
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.
Quoted 13 lines
Quoted 12 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 11 lines

Quoted 5 lines
Quoted 5 lines
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.

Quoted 7 lines

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.

Quoted 25 lines

Quoted 4 lines
Quoted 3 lines
o If a power-aware application receives user input, then that
application must be given the opportunity to process that input.
Quoted 8 lines
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.
Quoted 10 lines
Quoted 9 lines
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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 17 lines

Quoted 17 lines
Quoted 16 lines
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.)

Quoted 5 lines

Quoted 3 lines
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.

Quoted 10 lines

Quoted 9 lines
Quoted 5 lines
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.

Quoted 6 lines

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

Paul E. McKenney

author

2010-08-01 19:56 UTC #20 lore raw

Quoted 49 lines · Rafael J. Wysocki

Quoted 48 lines · Alan Stern
Quoted 26 lines · Paul E. McKenney
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.
Quoted 3 lines
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.
Quoted 13 lines
------------------------------------------------------------------------
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".

Quoted 8 lines

Quoted 4 lines
Quoted 4 lines
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".

Quoted 16 lines

Quoted 9 lines
Quoted 8 lines
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.
Quoted 6 lines
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.

Quoted 5 lines

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

Quoted 7 lines

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.

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 24 lines

Quoted 17 lines
Quoted 4 lines
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).
Quoted 10 lines
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.
Quoted 6 lines
Quoted 2 lines
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.)

Quoted 6 lines

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.

Quoted 20 lines

Quoted 4 lines
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.
Quoted 13 lines
Quoted 12 lines
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 11 lines

Quoted 5 lines
Quoted 5 lines
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.

Quoted 7 lines

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.

Quoted 25 lines

Quoted 4 lines
Quoted 3 lines
o If a power-aware application receives user input, then that
application must be given the opportunity to process that input.
Quoted 8 lines
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.
Quoted 10 lines
Quoted 9 lines
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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 17 lines

Quoted 17 lines
Quoted 16 lines
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.)

Quoted 5 lines

Quoted 3 lines
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.

Quoted 10 lines

Quoted 9 lines
Quoted 5 lines
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.

Quoted 6 lines

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

Rafael J. Wysocki

2010-08-01 22:44 UTC #21 lore raw

Quoted 3 lines · Paul E. McKenney

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Alan Stern
On Sat, 31 Jul 2010, Paul E. McKenney wrote:

...

Quoted 8 lines

Quoted 8 lines
Quoted 3 lines
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.

Quoted 5 lines

Quoted 2 lines
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.

...

Quoted 11 lines

Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
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.

Quoted 17 lines

Quoted 17 lines
Quoted 17 lines
Quoted 16 lines
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.)

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
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

Rafael J. Wysocki

2010-08-01 22:46 UTC #22 lore raw

Quoted 3 lines · Paul E. McKenney

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Alan Stern
On Sat, 31 Jul 2010, Paul E. McKenney wrote:

...

Quoted 8 lines

Quoted 8 lines
Quoted 3 lines
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.

Quoted 5 lines

Quoted 2 lines
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.

...

Quoted 11 lines

Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
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.

Quoted 17 lines

Quoted 17 lines
Quoted 17 lines
Quoted 16 lines
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.)

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
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

Paul E. McKenney

author

2010-08-02 00:32 UTC #23 lore raw

Quoted 16 lines · Rafael J. Wysocki

Quoted 3 lines · Paul E. McKenney
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Alan Stern
On Sat, 31 Jul 2010, Paul E. McKenney wrote:
...
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 2 lines
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!

Quoted 9 lines

...
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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".

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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. ;-)

Quoted 21 lines

Quoted 21 lines
Quoted 21 lines
Quoted 20 lines
Quoted 10 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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

Paul E. McKenney

author

2010-08-02 00:32 UTC #24 lore raw

Quoted 16 lines · Rafael J. Wysocki

Quoted 3 lines · Paul E. McKenney
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Alan Stern
On Sat, 31 Jul 2010, Paul E. McKenney wrote:
...
Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 2 lines
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!

Quoted 9 lines

...
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
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".

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
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. ;-)

Quoted 21 lines

Quoted 21 lines
Quoted 21 lines
Quoted 20 lines
Quoted 10 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
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

Arjan van de Ven

2010-08-01 04:52 UTC #25 lore raw

Quoted 8 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…

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.

Quoted 6 lines

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

Quoted 9 lines

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)

Arjan van de Ven

2010-08-01 04:52 UTC #26 lore raw

Quoted 8 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…

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.

Quoted 6 lines

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.

Quoted 9 lines

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.

Paul E. McKenney

author

2010-08-01 05:48 UTC #27 lore raw

Quoted 8 lines · Arjan van de Ven

Quoted 5 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 11 lines

Quoted 5 lines
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.

Quoted 10 lines

Quoted 9 lines
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.

Quoted 5 lines

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

Paul E. McKenney

author

2010-08-01 05:48 UTC #28 lore raw

Quoted 8 lines · Arjan van de Ven

Quoted 5 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 11 lines

Quoted 5 lines
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"....

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

Quoted 10 lines

Quoted 9 lines
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.

Quoted 5 lines

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)

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

Thanx, Paul

Arjan van de Ven

2010-08-01 06:00 UTC #29 lore raw

Quoted 13 lines · On Sat, 31 Jul 2010 22:48:16 -0700 "Paul E. McKenney"…

Quoted 12 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…
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.

Quoted 7 lines

Quoted 2 lines
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.

Quoted 7 lines

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)

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Paul E. McKenney

author

2010-08-01 19:12 UTC #30 lore raw

Quoted 28 lines · Arjan van de Ven

Quoted 13 lines · On Sat, 31 Jul 2010 22:48:16 -0700 "Paul E. McKenney"…
Quoted 12 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 7 lines

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.

Quoted 7 lines

Quoted 6 lines
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.

Quoted 9 lines

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

Paul E. McKenney

author

2010-08-01 19:12 UTC #31 lore raw

Quoted 28 lines · Arjan van de Ven

Quoted 13 lines · On Sat, 31 Jul 2010 22:48:16 -0700 "Paul E. McKenney"…
Quoted 12 lines · Arjan van de Ven
Quoted 8 lines · On Sat, 31 Jul 2010 10:58:42 -0700 "Paul E. McKenney"…
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 7 lines

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.

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

Quoted 7 lines

Quoted 6 lines
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.

Quoted 9 lines

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)

So, yes, you have done quite well.

Thanx, Paul

Ted Ts'o

2010-08-01 20:40 UTC #32 lore raw

Quoted 7 lines · Paul E. McKenney

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

Ted Ts'o

2010-08-01 22:43 UTC #33 lore raw

Quoted 7 lines · Paul E. McKenney

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.

- Ted

Arjan van de Ven

2010-08-01 23:00 UTC #34 lore raw

On Sun, 1 Aug 2010 16:40:26 -0400

Quoted 3 lines

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?

Quoted 10 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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.

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Arjan van de Ven

2010-08-01 23:00 UTC #35 lore raw

On Sun, 1 Aug 2010 16:40:26 -0400

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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

Quoted 8 lines

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

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Rafael J. Wysocki

2010-08-01 23:02 UTC #36 lore raw

Quoted 43 lines · Ted Ts'o

Quoted 7 lines · Paul E. McKenney
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.

Quoted 8 lines

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

Arjan van de Ven

2010-08-01 23:12 UTC #37 lore raw

Quoted 12 lines · 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....

Arjan van de Ven

2010-08-01 23:12 UTC #38 lore raw

Quoted 12 lines · 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....

David Brownell

2010-08-01 23:19 UTC #39 lore raw

Quoted 4 lines

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

David Brownell

2010-08-01 23:19 UTC #40 lore raw

Quoted 4 lines

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

Distinguish bugs from broken-by-design, too.

- Dave

James Bottomley

2010-08-01 23:30 UTC #41 lore raw

Quoted 4 lines · Ted Ts'o

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.

Quoted 3 lines

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

Quoted 6 lines

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

Quoted 8 lines

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.

Quoted 8 lines

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

James Bottomley

2010-08-01 23:30 UTC #42 lore raw

In reply to James Bottomley

Quoted 4 lines · Ted Ts'o

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.

Quoted 3 lines

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!

Quoted 6 lines

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

Quoted 8 lines

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

Quoted 8 lines

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

Ted Ts'o

2010-08-02 12:12 UTC #43 lore raw

Quoted 11 lines · James Bottomley

Quoted 4 lines · Ted Ts'o
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.

Quoted 5 lines

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

Quoted 2 lines

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

Ted Ts'o

2010-08-02 12:12 UTC #44 lore raw

Quoted 11 lines · James Bottomley

Quoted 4 lines · Ted Ts'o
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.

Quoted 5 lines

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.

Quoted 2 lines

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

- Ted

James Bottomley

2010-08-02 16:51 UTC #45 lore raw

Quoted 17 lines · Ted Ts'o

Quoted 5 lines · James Bottomley
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. :-)
Quoted 2 lines
Right, but this comes back to the axes of control. They have to be presented to the user in a simple but meaningful manner.

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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

James Bottomley

2010-08-02 16:51 UTC #46 lore raw

In reply to James Bottomley

Quoted 17 lines · Ted Ts'o

Quoted 5 lines · James Bottomley
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. :-)
Quoted 2 lines
Right, but this comes back to the axes of control. They have to be presented to the user in a simple but meaningful manner.

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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.

James

Ted Ts'o

2010-08-02 18:47 UTC #47 lore raw

Quoted 8 lines · James Bottomley

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

Ted Ts'o

2010-08-02 18:47 UTC #48 lore raw

Quoted 8 lines · James Bottomley

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.

- Ted

Paul E. McKenney

author

2010-08-02 03:03 UTC #49 lore raw

Quoted 9 lines · Ted Ts'o

Quoted 7 lines · Paul E. McKenney
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.

Quoted 11 lines

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.

Quoted 12 lines

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.

Quoted 9 lines

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.

Quoted 20 lines

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

Quoted 8 lines

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

Paul E. McKenney

author

2010-08-02 03:03 UTC #50 lore raw

Quoted 9 lines · Ted Ts'o

Quoted 7 lines · Paul E. McKenney
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.

Quoted 11 lines

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.

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

Quoted 12 lines

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.

Quoted 9 lines

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.

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

Quoted 20 lines

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

Quoted 8 lines

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

Arjan van de Ven

2010-08-02 04:05 UTC #51 lore raw

Quoted 9 lines · On Sun, 1 Aug 2010 20:03:04 -0700 "Paul E. McKenney"…

Quoted 4 lines
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.

[email protected]

2010-08-02 05:06 UTC #52 lore raw

Quoted 7 lines · Arjan van de Ven

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

Florian Mickler

2010-08-02 05:44 UTC #53 lore raw

Quoted 19 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:

Quoted 7 lines · Arjan van de Ven
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.

Quoted 6 lines

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

Florian Mickler

2010-08-02 05:44 UTC #54 lore raw

Quoted 19 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:

Quoted 7 lines · Arjan van de Ven
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.

Quoted 6 lines

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

Cheers,
Flo

[email protected]

2010-08-02 06:06 UTC #55 lore raw

Quoted 27 lines · Florian Mickler

Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?

Quoted 6 lines

Quoted 1 line
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

Florian Mickler

2010-08-02 06:40 UTC #56 lore raw

Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:

Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.

Quoted 6 lines

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

Florian Mickler

2010-08-02 06:40 UTC #57 lore raw

Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:

Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.

Quoted 6 lines

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

Cheers,
Flo

Florian Mickler

2010-08-02 06:53 UTC #58 lore raw

Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:

Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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

Quoted 9 lines

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

Florian Mickler

2010-08-02 06:53 UTC #59 lore raw

Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:

Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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

Quoted 9 lines

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)

hmmm..

Cheers,
Flo

[email protected]

2010-08-02 07:02 UTC #60 lore raw

Quoted 59 lines · Florian Mickler

Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:
Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 9 lines
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

Quoted 5 lines

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.

Quoted 3 lines

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

[email protected]

2010-08-02 07:03 UTC #61 lore raw

Quoted 59 lines · Florian Mickler

Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:
Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 9 lines
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

Quoted 5 lines

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.

Quoted 3 lines

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?

David Lang

Florian Mickler

2010-08-02 07:23 UTC #62 lore raw

Quoted 64 lines · On Mon, 2 Aug 2010 00:02:04 -0700 (PDT) [email protected] wrote:

Quoted 62 lines · Florian Mickler
Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:
Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 9 lines
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

Quoted 8 lines

Quoted 2 lines
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.

Quoted 13 lines

Quoted 3 lines
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?

Quoted 7 lines

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

Florian Mickler

2010-08-02 07:24 UTC #63 lore raw

Quoted 64 lines · On Mon, 2 Aug 2010 00:02:04 -0700 (PDT) [email protected] wrote:

Quoted 62 lines · Florian Mickler
Quoted 46 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:
Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 27 lines · Florian Mickler
Quoted 24 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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?
Quoted 6 lines
Quoted 1 line
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.
Quoted 6 lines
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
Quoted 9 lines
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

Quoted 8 lines

Quoted 2 lines
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.

Anyway... right. This is probably not a show-stopper.

Quoted 13 lines

Quoted 3 lines
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?

Quoted 7 lines

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

Cheers,
Flo

[email protected]

2010-08-02 09:06 UTC #64 lore raw

Quoted 73 lines · Florian Mickler

Quoted 62 lines · On Mon, 2 Aug 2010 00:02:04 -0700 (PDT) [email protected] wrote:
Quoted 42 lines · Florian Mickler
Quoted 39 lines · On Mon, 2 Aug 2010 08:40:03 +0200 Florian Mickler <[email protected]> wrote:
Quoted 36 lines · On Sun, 1 Aug 2010 23:06:08 -0700 (PDT) [email protected] wrote:
Quoted 33 lines · Florian Mickler
Quoted 19 lines · On Sun, 1 Aug 2010 22:06:34 -0700 (PDT) [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
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?
Quoted 7 lines
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

Quoted 7 lines

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

Paul Menage

2010-08-03 04:41 UTC #65 lore raw

Quoted 4 lines · 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

Paul Menage

2010-08-03 04:41 UTC #66 lore raw

Quoted 4 lines · 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.

(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

Florian Mickler

2010-08-03 11:26 UTC #67 lore raw

Quoted 12 lines · On Mon, 2 Aug 2010 21:41:17 -0700 Paul Menage <[email protected]> wrote:

Quoted 4 lines · 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.

Quoted 5 lines

(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

Florian Mickler

2010-08-03 11:26 UTC #68 lore raw

In reply to Paul Menage

Quoted 12 lines · On Mon, 2 Aug 2010 21:41:17 -0700 Paul Menage <[email protected]> wrote:

Quoted 4 lines · 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.

Quoted 5 lines

(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

Paul Menage

2010-08-03 04:38 UTC #69 lore raw

Quoted 3 lines · Florian Mickler

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.

Quoted 4 lines

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

Paul Menage

2010-08-03 04:38 UTC #70 lore raw

Quoted 3 lines · Florian Mickler

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.

Quoted 4 lines

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?

Paul

Florian Mickler

2010-08-03 11:25 UTC #71 lore raw

Hi!

Quoted 14 lines · On Mon, 2 Aug 2010 21:38:12 -0700 Paul Menage <[email protected]> wrote:

Quoted 3 lines · Florian Mickler
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.
Quoted 4 lines
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?

Quoted 6 lines

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

Florian Mickler

2010-08-03 11:25 UTC #72 lore raw

In reply to Paul Menage

Hi!

Quoted 14 lines · On Mon, 2 Aug 2010 21:38:12 -0700 Paul Menage <[email protected]> wrote:

Quoted 3 lines · Florian Mickler
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.
Quoted 4 lines
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?

Quoted 6 lines

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.

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

Paul E. McKenney

author

2010-08-02 14:09 UTC #73 lore raw

Quoted 19 lines · On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:

Quoted 7 lines · Arjan van de Ven
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.

Quoted 4 lines

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

Paul E. McKenney

author

2010-08-02 14:10 UTC #74 lore raw

Quoted 19 lines · On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:

Quoted 7 lines · Arjan van de Ven
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.

Quoted 4 lines

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

If I am misunderstanding your proposal, please enlighten me!

Thanx, Paul

[email protected]

2010-08-03 00:08 UTC #75 lore raw

Quoted 47 lines · Paul E. McKenney

Quoted 19 lines · On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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.
Quoted 4 lines
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.

Quoted 1 line

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

Arve Hjønnevåg

2010-08-03 03:21 UTC #76 lore raw

Quoted 60 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:

Quoted 48 lines · Paul E. McKenney
Quoted 20 lines · On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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.
Quoted 4 lines
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.
Quoted 1 line
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

Quoted 6 lines

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.

Quoted 13 lines

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

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-03 03:21 UTC #77 lore raw

Quoted 60 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:

Quoted 48 lines · Paul E. McKenney
Quoted 20 lines · On Sun, Aug 01, 2010 at 10:06:34PM -0700, [email protected] wrote:
Quoted 7 lines · Arjan van de Ven
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.
Quoted 4 lines
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.
Quoted 1 line
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

Quoted 6 lines

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.

Quoted 13 lines

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

Signature · 1 line

Arve Hjønnevåg

[email protected]

2010-08-03 04:44 UTC #78 lore raw

Quoted 19 lines · Arve Hj?nnev?g

Quoted 11 lines · 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
Quoted 6 lines
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.

Quoted 6 lines

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

[email protected]

2010-08-03 04:46 UTC #79 lore raw

Quoted 19 lines · Arve Hj?nnev?g

Quoted 11 lines · 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
Quoted 6 lines
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.

Quoted 6 lines

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?

David Lang

Arve Hjønnevåg

2010-08-03 05:01 UTC #80 lore raw

2010/8/2 <[email protected]>:

Quoted 32 lines · Arve Hj?nnev?g

Quoted 24 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 14 lines · Paul E. McKenney
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
Quoted 7 lines
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.
Quoted 6 lines
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.

Quoted 4 lines

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.

Quoted 22 lines

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

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-03 05:01 UTC #81 lore raw

2010/8/2 <[email protected]>:

Quoted 32 lines · Arve Hj?nnev?g

Quoted 24 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 14 lines · Paul E. McKenney
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
Quoted 7 lines
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.
Quoted 6 lines
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.

Quoted 4 lines

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?

Quoted 22 lines

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

Signature · 1 line

Arve Hjønnevåg

[email protected]

2010-08-03 05:06 UTC #82 lore raw

Quoted 38 lines · Arve Hj?nnev?g

2010/8/2 <[email protected]>:
Quoted 32 lines · Arve Hj?nnev?g
Quoted 24 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 14 lines · Paul E. McKenney
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
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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?

Quoted 4 lines

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

[email protected]

2010-08-03 05:07 UTC #83 lore raw

Quoted 38 lines · Arve Hj?nnev?g

2010/8/2 <[email protected]>:
Quoted 32 lines · Arve Hj?nnev?g
Quoted 24 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 14 lines · Paul E. McKenney
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
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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?

Quoted 4 lines

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.

David Lang

Arve Hjønnevåg

2010-08-03 22:47 UTC #84 lore raw

2010/8/2 <[email protected]>:

Quoted 49 lines · Arve Hj?nnev?g

Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.

Quoted 5 lines

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

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-03 22:47 UTC #85 lore raw

2010/8/2 <[email protected]>:

Quoted 49 lines · Arve Hj?nnev?g

Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.

Quoted 5 lines

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?

Signature · 1 line

Arve Hjønnevåg

[email protected]

2010-08-03 23:19 UTC #86 lore raw

Quoted 56 lines · Arve Hj?nnev?g

2010/8/2 <[email protected]>:
Quoted 49 lines · Arve Hj?nnev?g
Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
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?

Quoted 5 lines

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

[email protected]

2010-08-03 23:21 UTC #87 lore raw

Quoted 56 lines · Arve Hj?nnev?g

2010/8/2 <[email protected]>:
Quoted 49 lines · Arve Hj?nnev?g
Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
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?

Quoted 5 lines

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.

as I see it, suspending until a wakeup event (button press, incoming call, alarm, etc) is just another datapoint along the same path.

why should the suspend be put into a different category from the other low-power states?

David Lang

Paul E. McKenney

author

2010-08-04 00:10 UTC #88 lore raw

Quoted 86 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:

Quoted 56 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 49 lines · Arve Hj?nnev?g
Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
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?
Quoted 5 lines
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)

Quoted 2 lines

why should the suspend be put into a different category from the other low-power states?

OK, I'll bite...

Quoted 1 line

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

Paul E. McKenney

author

2010-08-04 00:10 UTC #89 lore raw

Quoted 86 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:

Quoted 56 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 49 lines · Arve Hj?nnev?g
Quoted 43 lines
2010/8/2 <[email protected]>:
Quoted 35 lines · Arve Hj?nnev?g
Quoted 26 lines · On Mon, Aug 2, 2010 at 5:08 PM, <[email protected]> wrote:
Quoted 15 lines · Paul E. McKenney
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
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
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?
Quoted 5 lines
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)

Quoted 2 lines

why should the suspend be put into a different category from the other low-power states?

OK, I'll bite...

Quoted 1 line

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.

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

[email protected]

2010-08-04 00:51 UTC #90 lore raw

Quoted 39 lines · Paul E. McKenney

Quoted 38 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 8 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 6 lines
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?
Quoted 5 lines
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)

Quoted 4 lines

Quoted 2 lines
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.

Quoted 5 lines

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.

Quoted 5 lines

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)

Quoted 8 lines

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)

Quoted 7 lines

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

Arve Hjønnevåg

2010-08-04 03:39 UTC #91 lore raw

Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:

Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.

Quoted 6 lines

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

Quoted 10 lines

Quoted 9 lines
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.)

Quoted 4 lines

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?

Quoted 8 lines

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

Quoted 8 lines

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.

Quoted 8 lines

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.

Quoted 8 lines

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)

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 03:39 UTC #92 lore raw

Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:

Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.

Quoted 6 lines

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)

Quoted 10 lines

Quoted 9 lines
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.)

Quoted 4 lines

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)

Quoted 8 lines

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

Quoted 8 lines

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.

Quoted 8 lines

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.

Quoted 8 lines

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)

Signature · 1 line

Arve Hjønnevåg

[email protected]

2010-08-04 04:47 UTC #93 lore raw

Quoted 79 lines · Arve Hj?nnev?g

Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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)

Quoted 5 lines

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?

Quoted 15 lines

Quoted 10 lines
Quoted 9 lines
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.)
Quoted 4 lines
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)

Quoted 8 lines

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.

Quoted 17 lines

Quoted 8 lines
Quoted 7 lines
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?
Quoted 8 lines
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.

Quoted 7 lines

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?

Quoted 10 lines

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

Quoted 7 lines

Quoted 7 lines
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)

Florian Mickler

2010-08-04 05:46 UTC #94 lore raw

Hi,

Quoted 8 lines · On Tue, 3 Aug 2010 21:47:49 -0700 (PDT) [email protected] wrote:

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

Quoted 7 lines

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

Florian Mickler

2010-08-04 05:46 UTC #95 lore raw

Hi,

Quoted 8 lines · On Tue, 3 Aug 2010 21:47:49 -0700 (PDT) [email protected] wrote:

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

Quoted 7 lines

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

Arve Hjønnevåg

2010-08-04 05:59 UTC #96 lore raw

2010/8/3 <[email protected]>:

Quoted 88 lines · Arve Hj?nnev?g

Quoted 87 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 84 lines · Paul E. McKenney
Quoted 45 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 43 lines · Arve Hj?nnev?g
Quoted 13 lines
2010/8/2 á<[email protected]>:
Quoted 10 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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)

Quoted 9 lines

Quoted 5 lines
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.

Quoted 26 lines

Quoted 17 lines
Quoted 10 lines
Quoted 9 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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?

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 28 lines

Quoted 20 lines
Quoted 16 lines
Quoted 8 lines
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)
Quoted 3 lines
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.
Quoted 7 lines
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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

or is it to prevent extranious wakeups?

That too.

Quoted 2 lines

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.

Quoted 12 lines

Quoted 12 lines
Quoted 11 lines
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)

Quoted 5 lines

Quoted 2 lines
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?

Quoted 11 lines

Quoted 11 lines
Quoted 11 lines
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)

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 05:59 UTC #97 lore raw

2010/8/3 <[email protected]>:

Quoted 88 lines · Arve Hj?nnev?g

Quoted 87 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 84 lines · Paul E. McKenney
Quoted 45 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 43 lines · Arve Hj?nnev?g
Quoted 13 lines
2010/8/2 á<[email protected]>:
Quoted 10 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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)

Quoted 9 lines

Quoted 5 lines
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.

Quoted 26 lines

Quoted 17 lines
Quoted 10 lines
Quoted 9 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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?

Quoted 6 lines

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.

Quoted 5 lines

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.

Quoted 28 lines

Quoted 20 lines
Quoted 16 lines
Quoted 8 lines
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)
Quoted 3 lines
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.
Quoted 7 lines
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.

Quoted 7 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

or is it to prevent extranious wakeups?

That too.

Quoted 2 lines

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.

Quoted 12 lines

Quoted 12 lines
Quoted 11 lines
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)

Quoted 5 lines

Quoted 2 lines
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?

Quoted 11 lines

Quoted 11 lines
Quoted 11 lines
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)

Signature · 1 line

Arve Hjønnevåg

[email protected]

2010-08-04 06:30 UTC #98 lore raw

Quoted 48 lines · Arve Hj?nnev?g

2010/8/3 <[email protected]>:
Quoted 47 lines · Arve Hj?nnev?g
Quoted 45 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 28 lines · Paul E. McKenney
Quoted 2 lines
OK, I'll bite...
thanks, this is not intended to be a trap.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
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).

Quoted 6 lines

Quoted 3 lines
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)

Quoted 28 lines

Quoted 28 lines
Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

Quoted 8 lines

Quoted 4 lines
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.

Quoted 29 lines

Quoted 29 lines
Quoted 19 lines
Quoted 15 lines
Quoted 7 lines
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)
Quoted 3 lines
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.
Quoted 7 lines
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.

Quoted 7 lines

Quoted 5 lines
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.

Quoted 10 lines

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

Quoted 3 lines

Quoted 2 lines
or is it to prevent extranious wakeups?
That too.

as noted above, this sounds like it's configurable.

Quoted 5 lines

Quoted 2 lines
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.

Quoted 12 lines

Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
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)

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
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

[email protected]

2010-08-04 06:32 UTC #99 lore raw

Quoted 48 lines · Arve Hj?nnev?g

2010/8/3 <[email protected]>:
Quoted 47 lines · Arve Hj?nnev?g
Quoted 45 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 28 lines · Paul E. McKenney
Quoted 2 lines
OK, I'll bite...
thanks, this is not intended to be a trap.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
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).

Quoted 6 lines

Quoted 3 lines
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)

Quoted 28 lines

Quoted 28 lines
Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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.

Quoted 6 lines

Quoted 3 lines
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.

again, this looks like suspend and idle are very closely related.

Quoted 8 lines

Quoted 4 lines
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.

Quoted 29 lines

Quoted 29 lines
Quoted 19 lines
Quoted 15 lines
Quoted 7 lines
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)
Quoted 3 lines
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.
Quoted 7 lines
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.

Quoted 7 lines

Quoted 5 lines
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.

Quoted 10 lines

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

Quoted 3 lines

Quoted 2 lines
or is it to prevent extranious wakeups?
That too.

as noted above, this sounds like it's configurable.

Quoted 5 lines

Quoted 2 lines
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.

Quoted 12 lines

Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
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)

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
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.

David Lang

Arve Hjønnevåg

2010-08-04 07:10 UTC #100 lore raw

2010/8/3 <[email protected]>:

Quoted 62 lines · Arve Hj?nnev?g

Quoted 61 lines
2010/8/3 <[email protected]>:
Quoted 58 lines · Arve Hj?nnev?g
Quoted 47 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 34 lines · Paul E. McKenney
Quoted 2 lines
OK, I'll bite...
thanks, this is not intended to be a trap.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 10 lines
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)
Quoted 5 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

Quoted 55 lines

so here suspend is looking like just a variation of low-power idle (different wakeup criteria)
Quoted 29 lines
Quoted 29 lines
Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 7 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 7 lines

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.

Quoted 45 lines

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.
Quoted 38 lines
Quoted 37 lines
Quoted 21 lines
Quoted 16 lines
Quoted 7 lines
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)
Quoted 4 lines
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.
Quoted 7 lines
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?

Quoted 6 lines

Quoted 1 line
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

Quoted 11 lines

Quoted 11 lines
Quoted 10 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 2 lines
or is it to prevent extranious wakeups?
That too.
as noted above, this sounds like it's configurable.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

Quoted 15 lines

Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 11 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
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.

Quoted 5 lines

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.

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 07:10 UTC #101 lore raw

2010/8/3 <[email protected]>:

Quoted 62 lines · Arve Hj?nnev?g

Quoted 61 lines
2010/8/3 <[email protected]>:
Quoted 58 lines · Arve Hj?nnev?g
Quoted 47 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 34 lines · Paul E. McKenney
Quoted 2 lines
OK, I'll bite...
thanks, this is not intended to be a trap.
Quoted 6 lines
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.
Quoted 7 lines
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.
Quoted 10 lines
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)
Quoted 5 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

Quoted 55 lines

so here suspend is looking like just a variation of low-power idle (different wakeup criteria)
Quoted 29 lines
Quoted 29 lines
Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 6 lines
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)
Quoted 8 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 7 lines
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.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 7 lines

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.

Quoted 45 lines

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.
Quoted 38 lines
Quoted 37 lines
Quoted 21 lines
Quoted 16 lines
Quoted 7 lines
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)
Quoted 4 lines
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.
Quoted 7 lines
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?

Quoted 6 lines

Quoted 1 line
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

Quoted 11 lines

Quoted 11 lines
Quoted 10 lines
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?

Quoted 6 lines

Quoted 2 lines
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.

Quoted 6 lines

Quoted 3 lines
Quoted 2 lines
or is it to prevent extranious wakeups?
That too.
as noted above, this sounds like it's configurable.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

Quoted 15 lines

Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 11 lines
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.

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
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.

Quoted 5 lines

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.

Signature · 1 line

Arve Hjønnevåg

Florian Mickler

2010-08-04 07:35 UTC #102 lore raw

Quoted 5 lines · On Wed, 4 Aug 2010 00:10:21 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 3 lines
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

Florian Mickler

2010-08-04 07:35 UTC #103 lore raw

Quoted 5 lines · On Wed, 4 Aug 2010 00:10:21 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 3 lines
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.

Cheers,
Flo

[email protected]

2010-08-04 07:42 UTC #104 lore raw

Quoted 19 lines · Arve Hj?nnev?g

2010/8/3 <[email protected]>:
Quoted 18 lines · Arve Hj?nnev?g
Quoted 16 lines
2010/8/3 <[email protected]>:
Quoted 10 lines · Arve Hj?nnev?g
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.

Quoted 8 lines

Quoted 3 lines
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.

Quoted 9 lines

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

Quoted 88 lines

Quoted 45 lines
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.
Quoted 38 lines
Quoted 37 lines
Quoted 21 lines
Quoted 16 lines
Quoted 7 lines
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)
Quoted 4 lines
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.
Quoted 7 lines
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?
Quoted 6 lines
Quoted 1 line
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
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
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?
Quoted 6 lines
Quoted 2 lines
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.
Quoted 12 lines
Quoted 3 lines
Quoted 2 lines
or is it to prevent extranious wakeups?
That too.
as noted above, this sounds like it's configurable.
Quoted 5 lines
Quoted 2 lines
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.

Quoted 7 lines

Quoted 2 lines
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)

Quoted 31 lines

Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.

Quoted 4 lines

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

Rafael J. Wysocki

2010-08-04 11:47 UTC #105 lore raw

Quoted 8 lines · On Wednesday, August 04, 2010, [email protected] wrote:

Quoted 6 lines · Arve Hj?nnev?g
2010/8/3 <[email protected]>:
Quoted 5 lines · Arve Hj?nnev?g
Quoted 4 lines
2010/8/3 <[email protected]>:
Quoted 2 lines · Arve Hj?nnev?g

...

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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.

Quoted 18 lines

Quoted 13 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 4 lines
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.

Quoted 9 lines

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

Rafael J. Wysocki

2010-08-04 11:49 UTC #106 lore raw

Quoted 8 lines · On Wednesday, August 04, 2010, [email protected] wrote:

Quoted 6 lines · Arve Hj?nnev?g
2010/8/3 <[email protected]>:
Quoted 5 lines · Arve Hj?nnev?g
Quoted 4 lines
2010/8/3 <[email protected]>:
Quoted 2 lines · Arve Hj?nnev?g

...

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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.

Quoted 18 lines

Quoted 13 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 4 lines
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.

Quoted 9 lines

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)

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.

Thanks,
Rafael

[email protected]

2010-08-04 18:51 UTC #107 lore raw

Quoted 10 lines · Rafael J. Wysocki

Quoted 8 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 6 lines · Arve Hj?nnev?g
2010/8/3 <[email protected]>:
Quoted 5 lines · Arve Hj?nnev?g
Quoted 4 lines
2010/8/3 <[email protected]>:
Quoted 2 lines · Arve Hj?nnev?g
...

Quoted 8 lines

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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)

Quoted 37 lines

Quoted 18 lines
Quoted 13 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
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.

Quoted 2 lines

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

Quoted 5 lines

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.

Quoted 5 lines

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

Rafael J. Wysocki

2010-08-04 20:31 UTC #108 lore raw

Quoted 77 lines · On Wednesday, August 04, 2010, [email protected] wrote:

Quoted 10 lines · Rafael J. Wysocki
Quoted 8 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 6 lines · Arve Hj?nnev?g
2010/8/3 <[email protected]>:
Quoted 5 lines · Arve Hj?nnev?g
Quoted 4 lines
2010/8/3 <[email protected]>:
Quoted 2 lines · Arve Hj?nnev?g
...
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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)
Quoted 37 lines
Quoted 18 lines
Quoted 13 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
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
Quoted 5 lines
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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 10 lines

Quoted 5 lines
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

Rafael J. Wysocki

2010-08-04 20:33 UTC #109 lore raw

Quoted 77 lines · On Wednesday, August 04, 2010, [email protected] wrote:

Quoted 10 lines · Rafael J. Wysocki
Quoted 8 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 6 lines · Arve Hj?nnev?g
2010/8/3 <[email protected]>:
Quoted 5 lines · Arve Hj?nnev?g
Quoted 4 lines
2010/8/3 <[email protected]>:
Quoted 2 lines · Arve Hj?nnev?g
...
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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)
Quoted 37 lines
Quoted 18 lines
Quoted 13 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
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
Quoted 5 lines
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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 10 lines

Quoted 5 lines
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.

Thanks,
Rafael

[email protected]

2010-08-04 23:04 UTC #110 lore raw

Quoted 10 lines · Rafael J. Wysocki

Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 7 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 6 lines

Quoted 3 lines
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?

Quoted 33 lines

Quoted 3 lines
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.
Quoted 10 lines
Quoted 5 lines
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.

Quoted 3 lines

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

Rafael J. Wysocki

2010-08-04 23:26 UTC #111 lore raw

Quoted 16 lines · On Thursday, August 05, 2010, [email protected] wrote:

Quoted 14 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 10 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 5 lines

Quoted 2 lines
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.

Quoted 33 lines

Quoted 33 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 5 lines
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.

Quoted 8 lines

Quoted 3 lines
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

Rafael J. Wysocki

2010-08-04 23:28 UTC #112 lore raw

Quoted 16 lines · On Thursday, August 05, 2010, [email protected] wrote:

Quoted 14 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 10 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 5 lines

Quoted 2 lines
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.

Quoted 33 lines

Quoted 33 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 5 lines
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.

Quoted 8 lines

Quoted 3 lines
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)

Thanks,
Rafael

[email protected]

2010-08-04 23:39 UTC #113 lore raw

Quoted 17 lines · Rafael J. Wysocki

Quoted 16 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 14 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 10 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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

[email protected]

2010-08-04 23:41 UTC #114 lore raw

Quoted 17 lines · Rafael J. Wysocki

Quoted 16 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 14 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 10 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
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.

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

Rafael J. Wysocki

2010-08-05 00:10 UTC #115 lore raw

Quoted 25 lines · On Thursday, August 05, 2010, [email protected] wrote:

Quoted 23 lines · Rafael J. Wysocki
Quoted 21 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 10 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 7 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.
Quoted 6 lines
Quoted 3 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

Quoted 2 lines

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

[email protected]

2010-08-05 13:21 UTC #116 lore raw

Quoted 41 lines · Rafael J. Wysocki

Quoted 25 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 23 lines · Rafael J. Wysocki
Quoted 21 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 10 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 7 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.
Quoted 6 lines
Quoted 3 lines
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?
Quoted 7 lines
Quoted 2 lines
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).

Quoted 3 lines

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.

Quoted 4 lines

Quoted 2 lines
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

[email protected]

2010-08-05 13:23 UTC #117 lore raw

Quoted 41 lines · Rafael J. Wysocki

Quoted 25 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 23 lines · Rafael J. Wysocki
Quoted 21 lines · On Thursday, August 05, 2010, [email protected] wrote:
Quoted 10 lines · Rafael J. Wysocki
Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 7 lines · On Wednesday, August 04, 2010, [email protected] wrote:
Quoted 5 lines · Rafael J. Wysocki
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.
Quoted 6 lines
Quoted 3 lines
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?
Quoted 7 lines
Quoted 2 lines
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).

Quoted 3 lines

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.

Quoted 4 lines

Quoted 2 lines
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

Olivier Galibert

2010-08-04 04:58 UTC #118 lore raw

In reply to Olivier Galibert

Quoted 4 lines · Arve Hjønnevåg

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.

Arve Hjønnevåg

2010-08-04 06:03 UTC #119 lore raw

2010/8/3 Olivier Galibert <[email protected]>:

Quoted 8 lines · Arve Hjønnevåg

Quoted 4 lines
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.

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 06:03 UTC #120 lore raw

2010/8/3 Olivier Galibert <[email protected]>:

Quoted 8 lines · Arve Hjønnevåg

Quoted 4 lines
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.

Signature · 1 line

Arve Hjønnevåg

Olivier Galibert

2010-08-04 06:28 UTC #121 lore raw

Quoted 7 lines · Arve Hjønnevåg

2010/8/3 Olivier Galibert <[email protected]>:
Quoted 6 lines · Arve Hjønnevåg
Quoted 4 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

Olivier Galibert

2010-08-04 06:28 UTC #122 lore raw

In reply to Olivier Galibert

Quoted 7 lines · Arve Hjønnevåg

2010/8/3 Olivier Galibert <[email protected]>:
Quoted 6 lines · Arve Hjønnevåg
Quoted 4 lines
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?

Quoted 7 lines

Quoted 2 lines
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.

OG.

Arve Hjønnevåg

2010-08-04 06:50 UTC #123 lore raw

2010/8/3 Olivier Galibert <[email protected]>:

Quoted 11 lines · Arve Hjønnevåg

Quoted 10 lines
2010/8/3 Olivier Galibert <[email protected]>:
Quoted 8 lines · Arve Hjønnevåg
Quoted 4 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

it's just another idle level. And from a power management code/policy decisions point of view, it should be the same.

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 06:50 UTC #124 lore raw

2010/8/3 Olivier Galibert <[email protected]>:

Quoted 11 lines · Arve Hjønnevåg

Quoted 10 lines
2010/8/3 Olivier Galibert <[email protected]>:
Quoted 8 lines · Arve Hjønnevåg
Quoted 4 lines
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.

Quoted 7 lines

Quoted 4 lines
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.

Quoted 5 lines

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.

Quoted 7 lines

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,

Quoted 3 lines

it's just another idle level. And from a power management code/policy decisions point of view, it should be the same.

Signature · 1 line

Arve Hjønnevåg

Paul E. McKenney

author

2010-08-04 16:27 UTC #125 lore raw

Quoted 98 lines · Arve Hjønnevåg

Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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).
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 3 lines
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)

Quoted 8 lines

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

Quoted 50 lines

Quoted 8 lines
Quoted 7 lines
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?
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
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)
Signature · 1 line
Arve Hjønnevåg

Paul E. McKenney

author

2010-08-04 16:27 UTC #126 lore raw

Quoted 98 lines · Arve Hjønnevåg

Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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).
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 3 lines
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)

Quoted 8 lines

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

3. Your proposal here. ;-)

Thoughts?

Thanx, Paul

Quoted 50 lines

Quoted 8 lines
Quoted 7 lines
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?
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 8 lines
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)
Signature · 1 line
Arve Hjønnevåg

Rafael J. Wysocki

2010-08-04 20:43 UTC #127 lore raw

Quoted 108 lines · Paul E. McKenney

Quoted 98 lines · Arve Hjønnevåg
Quoted 71 lines · On Tue, Aug 3, 2010 at 5:51 PM, <[email protected]> wrote:
Quoted 43 lines · Paul E. McKenney
Quoted 42 lines · On Tue, Aug 03, 2010 at 04:19:25PM -0700, [email protected] wrote:
Quoted 11 lines · Arve Hj?nnev?g
2010/8/2 <[email protected]>:
Quoted 9 lines
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?
Quoted 5 lines
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)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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).
Quoted 9 lines
Quoted 8 lines
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.)
Quoted 3 lines
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)
Quoted 8 lines
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?

Quoted 3 lines

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

Quoted 13 lines

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.

Quoted 9 lines

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.

Quoted 3 lines

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

Arjan van de Ven

2010-08-04 03:57 UTC #128 lore raw

Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…

OK, I'll bite...
Quoted 1 line
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)

Quoted 6 lines

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)

Quoted 9 lines

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.

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Arjan van de Ven

2010-08-04 03:58 UTC #129 lore raw

Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…

OK, I'll bite...
Quoted 1 line
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.

Quoted 6 lines

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.

Quoted 9 lines

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

Signature · 3 lines

Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

[email protected]

2010-08-04 04:55 UTC #130 lore raw

Quoted 11 lines · Arjan van de Ven

Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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.

Quoted 6 lines

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

Florian Mickler

2010-08-04 06:12 UTC #131 lore raw

Quoted 29 lines · On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) [email protected] wrote:

Quoted 11 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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.
Quoted 6 lines
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.

Quoted 6 lines

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

Florian Mickler

2010-08-04 06:12 UTC #132 lore raw

Quoted 29 lines · On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) [email protected] wrote:

Quoted 11 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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.
Quoted 6 lines
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.

Quoted 6 lines

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

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.

hmmm...

Cheers,
Flo

[email protected]

2010-08-04 06:48 UTC #133 lore raw

Quoted 39 lines · Florian Mickler

Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 34 lines · On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) [email protected] wrote:
Quoted 11 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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.
Quoted 6 lines
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.

Quoted 7 lines

Quoted 1 line
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

Quoted 3 lines

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.

Quoted 10 lines

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

[email protected]

2010-08-04 06:49 UTC #134 lore raw

Quoted 39 lines · Florian Mickler

Subject: Re: Attempted summary of suspend-blockers LKML thread
Quoted 34 lines · On Tue, 3 Aug 2010 21:55:07 -0700 (PDT) [email protected] wrote:
Quoted 11 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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.
Quoted 6 lines
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.

Quoted 7 lines

Quoted 1 line
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

Quoted 3 lines

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.

Quoted 10 lines

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.

Since powertop was designed to find ill-bahaved applications, you would still be able to point the finger at the offenders.

David Lang

Arve Hjønnevåg

2010-08-04 05:22 UTC #135 lore raw

Quoted 47 lines · Arjan van de Ven

Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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)
Quoted 6 lines
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)
Quoted 9 lines
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.)

Quoted 11 lines

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.

Signature · 1 line

Arve Hjønnevåg

Arve Hjønnevåg

2010-08-04 05:23 UTC #136 lore raw

Quoted 47 lines · Arjan van de Ven

Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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)
Quoted 6 lines
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)
Quoted 9 lines
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.)

Quoted 11 lines

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.

Signature · 1 line

Arve Hjønnevåg

Igor Stoppa

2010-08-04 06:43 UTC #137 lore raw

On 08/04/2010 08:22 AM, ext Arve Hjønnevåg wrote:

[snip ... discussion about wakeup sources]

Quoted 8 lines

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.

wrt wakeup sources: why isn't it possible to just expect the interrupt associated to the undesired wakeup src to be masked?
That should be possible on any platform, and I would expect the hw to keep track that at least 1 irq has happened for a specific device:
I'm assuming that the system is fast enough to serve the irq before another one of same type is generated, should it be considered worth of waking up the system.

Timers might be tricky (iirc only 2 out of 12 timers are wakeup sources on OMAP3), but many other peripherals should be easier to handle.

cheers, igor

Paul E. McKenney

author

2010-08-04 18:39 UTC #138 lore raw

Quoted 60 lines · Arve Hjønnevåg

Quoted 47 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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)
Quoted 6 lines
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)
Quoted 9 lines
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.)
Quoted 11 lines
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.

Quoted 6 lines

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

Paul E. McKenney

author

2010-08-04 18:40 UTC #139 lore raw

Quoted 60 lines · Arve Hjønnevåg

Quoted 47 lines · Arjan van de Ven
Quoted 8 lines · On Tue, 3 Aug 2010 17:10:15 -0700 "Paul E. McKenney"…
OK, I'll bite...
Quoted 1 line
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)
Quoted 6 lines
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)
Quoted 9 lines
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.)
Quoted 11 lines
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.

Quoted 6 lines

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

Paul E. McKenney

author

2010-08-04 18:32 UTC #140 lore raw