Suspend block api (version 8)

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

It was apparently hidden on some funky list.

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

It was apparently hidden on some funky list.

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

Quoted 37 lines · James Bottomley

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 7 lines

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

At least it would be good style for a topic which is

1) contended like this one

2) pushing an intrusive feature last minute which has been merged into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Quoted 37 lines · James Bottomley

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 7 lines

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

At least it would be good style for a topic which is

1) contended like this one

2) pushing an intrusive feature last minute which has been merged into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Quoted 2 lines · Thomas Gleixner

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

Quoted 2 lines · Thomas Gleixner

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

Quoted 9 lines · James Bottomley

Quoted 2 lines · Thomas Gleixner

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

And yet, the OSS drivers are *still* in-tree, even though similar arguments apply to an OSS->ALSA migration. And there's a bunch of other stuff in Documentation/feature-removal-schedule.txt in a similar situation.

Quoted 9 lines · James Bottomley

Quoted 2 lines · Thomas Gleixner

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

And yet, the OSS drivers are *still* in-tree, even though similar arguments apply to an OSS->ALSA migration. And there's a bunch of other stuff in Documentation/feature-removal-schedule.txt in a similar situation.

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:

Quoted 2 lines

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:

Quoted 2 lines

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it. Even on those platforms that do support it, we can translate most

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

Quoted 1 line · James Bottomley

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:

[...]

Quoted 3 lines

Quoted 2 lines

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Quoted 3 lines

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it.  Even on those platforms that do support it, we can translate most

You completely missed the point: The crappy user interface - and interferences with pother subsystems - must be maintained for ages - and that is independent if one uses it or not. Even worse if it's not widely used.

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

Quoted 1 line · James Bottomley

On Wed, 2010-05-26 at 19:51 +0200, Thomas Gleixner wrote:

[...]

Quoted 3 lines

Quoted 2 lines

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Quoted 3 lines

I really don't see how it is ... the ABI comes with a switch that allows it to be disabled, so only platforms wishing to use it have to support it.  Even on those platforms that do support it, we can translate most

You completely missed the point: The crappy user interface - and interferences with pother subsystems - must be maintained for ages - and that is independent if one uses it or not. Even worse if it's not widely used.

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

Quoted 7 lines

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly.

Quoted 8 lines · On Thu, 27 May 2010 02:07:21 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 7 lines

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

Quoted 7 lines

This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly.

So here is my suggestion.
Rather than trying to push a feature that is clearly meeting lots of resistance, the Android devs should state the problem as a bug that needs fixing.  As you have.
Upstream is a lot more receptive of fixing bugs than adding features.

In this case the bug is that you cannot suspend without the risk of losing wakeup events.  This is a real bug that for your use case is a serious bug.  I've toyed with several ways of fixing this but the one that seems most promising is to note that in the kernel the suspend process is two-stage with a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction and so ends up with a race.

Maybe userspace should be able to say "prepare to suspend" with the meaning that after a successful return, any event which would cause a wakeup sets a flag so that the final suspend returns immediately (without actually going to the lower power state).

Then your opportunistic suspend could be entirely in userspace where you wouldn't have to fight with the kernel crowd :-)
The suspend-daemon would:
 Wait for all user-space suspend blocks to be dropped.
 Tell the kernel to "prepare to suspend".
 Tell all userspace programs which have registered for the message that they should prepare to suspend.  They have the opportunity at this point to take out a new suspend block if they notice an event that has just arrived
 Wait for all those programs to acknowledge
 If there are no new suspend blocks, tell the kernel to suspend else tell the kernel to abort the suspend.

This (I think) allows race-free opportunistic suspend in user-space where you can do all the accounting you need.

I don't fully understand your requirements for accounting of devices drivers rejecting or blocking a suspend, so I cannot say precisely how that would fit in.  Maybe you just need to know - whenever the 'suspend request' completes - what the wakeup events were.  It shouldn't be too hard to export that to user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for requesting a suspend, but I suspect it should expose each of suspend_prepare
 suspend_devices_and_enter
 suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to "open-for-write", "write", "close", but I'm not sure that suspend_prepare would be appropriate if the app was about to write "disk" - it is a pity that both suspend and hibernate use the same sysfs file.

So just fix the bug, and everyone will be happy :-)

2010/5/27 Neil Brown <[email protected]>:

Quoted 50 lines

Quoted 8 lines · On Thu, 27 May 2010 02:07:21 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 7 lines

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

Quoted 7 lines

This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly.

So here is my suggestion.
Rather than trying to push a feature that is clearly meeting lots of resistance, the Android devs should state the problem as a bug that needs fixing.  As you have.
Upstream is a lot more receptive of fixing bugs than adding features.

In this case the bug is that you cannot suspend without the risk of losing wakeup events.  This is a real bug that for your use case is a serious bug.  I've toyed with several ways of fixing this but the one that seems most promising is to note that in the kernel the suspend process is two-stage with a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction and so ends up with a race.

Maybe userspace should be able to say "prepare to suspend" with the meaning that after a successful return, any event which would cause a wakeup sets a flag so that the final suspend returns immediately (without actually going to the lower power state).

Then your opportunistic suspend could be entirely in userspace where you wouldn't have to fight with the kernel crowd :-)
The suspend-daemon would:
 Wait for all user-space suspend blocks to be dropped.
 Tell the kernel to "prepare to suspend".
 Tell all userspace programs which have registered for the message that they should prepare to suspend.  They have the opportunity at this point to take out a new suspend block if they notice an event that has just arrived
 Wait for all those programs to acknowledge
 If there are no new suspend blocks, tell the kernel to suspend else tell the kernel to abort the suspend.

Quoted 3 lines

This (I think) allows race-free opportunistic suspend in user-space where you can do all the accounting you need.

Perhaps, but it forces all user space programs that get events from the kernel to also receive messages from the suspend-daemon, check for other events again, then respond to the suspend-daemon. The current suspend blocker interface is easier to use.

I don't see how your
suggestion avoids races for events that pass trough several kernel layers though. If a wakeup event happened before the "prepare to suspend" call but has not yet been passed to user-space, the user-space program that needs this event will not know that it needs to block suspend when it gets the prepare-to-suspend message.

Quoted 17 lines

I don't fully understand your requirements for accounting of devices drivers rejecting or blocking a suspend, so I cannot say precisely how that would fit in.  Maybe you just need to know - whenever the 'suspend request' completes - what the wakeup events were.  It shouldn't be too hard to export that to user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for requesting a suspend, but I suspect it should expose each of suspend_prepare
 suspend_devices_and_enter
 suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to "open-for-write", "write", "close", but I'm not sure that suspend_prepare would be appropriate if the app was about to write "disk" - it is a pity that both suspend and hibernate use the same sysfs file.

Quoted 2 lines

So just fix the bug, and everyone will be happy :-)

I already have, but everyone do not appear to be happy.

Quoted 51 lines · On Thu, 27 May 2010 21:57:02 -0700 Arve Hjønnevåg <[email protected]> wrote:

2010/5/27 Neil Brown <[email protected]>:

Quoted 50 lines

Quoted 8 lines · On Thu, 27 May 2010 02:07:21 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 7 lines

Quoted 3 lines

of it into pm QoS stuff and if one day someone solves the rogue app problem, we can migrate over.

If it's so important for Android and no one else, Android can carry it out of tree.

Quoted 7 lines

This is not only important for Android. If you use suspend on a current Linux system you run the risk of loosing wakeup events. If you have wakeup events that you cannot afford to lose your only option is to never suspend. On some hardware (e.g. x86) the cost of not suspending is always huge, on other hardware (many ARM SOCs) the cost is only huge if your apps behave poorly.

So here is my suggestion.
Rather than trying to push a feature that is clearly meeting lots of resistance, the Android devs should state the problem as a bug that needs fixing.  As you have.
Upstream is a lot more receptive of fixing bugs than adding features.

In this case the bug is that you cannot suspend without the risk of losing wakeup events.  This is a real bug that for your use case is a serious bug.  I've toyed with several ways of fixing this but the one that seems most promising is to note that in the kernel the suspend process is two-stage with a 'prepare' followed by a 'suspend'. Userspace cannot make that distinction and so ends up with a race.

Maybe userspace should be able to say "prepare to suspend" with the meaning that after a successful return, any event which would cause a wakeup sets a flag so that the final suspend returns immediately (without actually going to the lower power state).

Then your opportunistic suspend could be entirely in userspace where you wouldn't have to fight with the kernel crowd :-)
The suspend-daemon would:
 Wait for all user-space suspend blocks to be dropped.
 Tell the kernel to "prepare to suspend".
 Tell all userspace programs which have registered for the message that they should prepare to suspend.  They have the opportunity at this point to take out a new suspend block if they notice an event that has just arrived
 Wait for all those programs to acknowledge
 If there are no new suspend blocks, tell the kernel to suspend else tell the kernel to abort the suspend.

Quoted 8 lines

Quoted 3 lines

This (I think) allows race-free opportunistic suspend in user-space where you can do all the accounting you need.

Perhaps, but it forces all user space programs that get events from the kernel to also receive messages from the suspend-daemon, check for other events again, then respond to the suspend-daemon. The current suspend blocker interface is easier to use.

Maybe so.  There are quite possibly better ways to fix the bug.  There are a variety of different tradeoffs possible and I suspect we could have fun arguing about those.  My main point though is that if we focus on a bug that needs to be fixed, we should be able to keep the conversation more focussed. Currently it seems to be branching all over the place which doesn't seem very helpful.

Quoted 6 lines

                                             I don't see how your suggestion avoids races for events that pass trough several kernel layers though. If a wakeup event happened before the "prepare to suspend" call but has not yet been passed to user-space, the user-space program that needs this event will not know that it needs to block suspend when it gets the prepare-to-suspend message.

Each layer must understand that the event is a wake-up event, and the "prepare to suspend call" to each layer should drive all pending events through to the next layer.  If the layers (drivers) are prepared in the "right" order, this will force the event all the way to user-space.  If they are called in exactly the "Wrong" order, this will require multiple prepare/suspend/instant-resume cycles to get the event through, but I suspect that this would very rarely result in truly pathological behaviour.

I'm guessing your current code (sorry, I haven't looked at all) already tracks events up through multiple layers so they can interact with a pending opporunistic-suspend request.  I suspect that aspect of the code isn't particularly controversial.
Keep that, and use it precisely to implement a race-free "suspend" request from user-space.

Quoted 20 lines

Quoted 19 lines

I don't fully understand your requirements for accounting of devices drivers rejecting or blocking a suspend, so I cannot say precisely how that would fit in.  Maybe you just need to know - whenever the 'suspend request' completes - what the wakeup events were.  It shouldn't be too hard to export that to user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for requesting a suspend, but I suspect it should expose each of suspend_prepare
 suspend_devices_and_enter
 suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to "open-for-write", "write", "close", but I'm not sure that suspend_prepare would be appropriate if the app was about to write "disk" - it is a pity that both suspend and hibernate use the same sysfs file.

So just fix the bug, and everyone will be happy :-)

Quoted 2 lines

I already have, but everyone do not appear to be happy.

I don't think you have.  You have proposed a significant new feature: a suspend-as-soon-as-you-can request which *user*space*can*block*.  People don't like that because it seems like a poor second cousin to something that would be really useful (user-space setting more general latency requirements).

I am suggesting that you stick with the feature we have, which is that user-space can request a suspend and the kernel/hardware can cause a subsequent (possibly immediate) resume in response to a wake-up event.

Argue that the current definition of "wake-up event" is too weak and does not allow the feature to be used safely.  Present an implementation (I suspect you have most of it already) where a wake-up event is tracked all the way from the hardware to user-space and is still a 'wake-up event' until userspace actually consumes it.

Then user-space simply has to:
 poll for event to be ready
 request suspend-block in user-space
 consume event
 handle event
 release suspend-block
 loop

No change to API.  No new concepts.  Simply a bug and a direct fix.

You probably want the "suspend" request to block until there are no pending events (and then immediately fail if there were) so that there is no risk of the suspend-daemon spinning asking of a suspend which appears to resume immediately (until some other process sees an event and blocks suspend.

NeilBrown

Quoted 16 lines

I don't fully understand your requirements for accounting of devices drivers rejecting or blocking a suspend, so I cannot say precisely how that would fit in.  Maybe you just need to know - whenever the 'suspend request' completes - what the wakeup events were.  It shouldn't be too hard to export that to user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for requesting a suspend, but I suspect it should expose each of suspend_prepare
 suspend_devices_and_enter
 suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to "open-for-write", "write", "close", but I'm not sure that suspend_prepare would be appropriate if the app was about to write "disk" - it is a pity that both suspend and hibernate use the same sysfs file.

Quoted 2 lines

So just fix the bug, and everyone will be happy :-)

I already have, but everyone do not appear to be happy.

Hi!

Quoted 16 lines

Quoted 16 lines

I don't fully understand your requirements for accounting of devices drivers rejecting or blocking a suspend, so I cannot say precisely how that would fit in.  Maybe you just need to know - whenever the 'suspend request' completes - what the wakeup events were.  It shouldn't be too hard to export that to user-space via sysfs.

I won't propose an exact enhancement to the user-space interface for requesting a suspend, but I suspect it should expose each of suspend_prepare
 suspend_devices_and_enter
 suspend_finish
(or close analogues there-of) to user-space.  It is tempting to map those to "open-for-write", "write", "close", but I'm not sure that suspend_prepare would be appropriate if the app was about to write "disk" - it is a pity that both suspend and hibernate use the same sysfs file.

Quoted 4 lines

Quoted 2 lines

So just fix the bug, and everyone will be happy :-)

I already have, but everyone do not appear to be happy.

Half of the code you submitted was infrastructure for debugging userspace. Sorry, that does not count as a bugfix.

Quoted 40 lines · James Bottomley

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

Quoted 4 lines

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

At least it would be good style for a topic which is

1) contended like this one

2) pushing an intrusive feature last minute which has been merged into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Thanks,

tglx

Quoted 40 lines · James Bottomley

Quoted 17 lines · Peter Zijlstra

Quoted 16 lines · Pavel Machek

Quoted 15 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

You mean this one:

https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025689.html

?

Quoted 1 line

It was apparently hidden on some funky list.

Sending a PM pull request to the PM list doesn't really strike me as the height of obfuscation. Plus almost everyone who objected was on the cc list.

Quoted 2 lines

Hiding pull requests is bad enough, but hiding pull requests for
contended features is just plain wrong.

Quoted 4 lines

I don't think it's a conspiracy ... just standard operating procedure for this subsystem. I do think cc'ing lkml is good practise (having been yelled at for not doing that in the past) but it's certainly not universal practise.

At least it would be good style for a topic which is

1) contended like this one

2) pushing an intrusive feature last minute which has been merged into the pm tree barely two days ago.

Darn, _we_ have to deal with that forever as it sets a crappy user space ABI in stone.

Thanks,

tglx

Quoted 20 lines · Pavel Machek

Quoted 18 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

Quoted 2 lines

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

It was apparently hidden on some funky list. Hiding pull requests is bad enough, but hiding pull requests for contended features is just plain wrong.

Quoted 20 lines · Pavel Machek

Quoted 18 lines · Peter Zijlstra

Quoted 10 lines · James Bottomley

Quoted 2 lines

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

It's a fairly large piece of code to try to rewrite in C, so I don't think that's feasible on a reasonable timescale. Android does have the concept of special sockets that can be used to communicate from less to more privileged processes (it has a very segmented runtime model), so these might be usable ... they have a drawback that they're essentially named pipes, so no multiplexing, but one per suspend influencing C process shouldn't be a huge burden.

It wouldn't need to convert the whole Frameworks layer into C, just enough to manage the suspend state.

Anyway, I think there's been enough arguments against even the concept of opportunistic/auto-suspend, and I for one will object with a NAK if Rafael send this to Linus.

Quoted 2 lines

It was submitted already. I tried to followup with NAK, but can't currently see it in the archive.

It was apparently hidden on some funky list. Hiding pull requests is bad enough, but hiding pull requests for contended features is just plain wrong.

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

This is an incorrect statement.  It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out).  It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this).  The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

This is an incorrect statement.  It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out).  It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this).  The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Hi James,

Quoted 2 lines · Pekka Enberg

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

Quoted 9 lines · James Bottomley

This is an incorrect statement. It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out). It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this). The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Incorrect statement how exactly? A JVM can do mmap(), for example, just fine through FileChannel.map() so there's no need for heavy-weight RPC.

Furthermore, the whole discussion is moot anyway as
Android runs Dalvik which can be hacked to support whatever communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is hard" nonsense and concentrate on real issues?

Hi James,

Quoted 2 lines · Pekka Enberg

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

Quoted 9 lines · James Bottomley

This is an incorrect statement. It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out). It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this). The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Incorrect statement how exactly? A JVM can do mmap(), for example, just fine through FileChannel.map() so there's no need for heavy-weight RPC.

Furthermore, the whole discussion is moot anyway as
Android runs Dalvik which can be hacked to support whatever communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is hard" nonsense and concentrate on real issues?

Quoted 16 lines · Pekka Enberg

Quoted 2 lines

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

Quoted 9 lines · James Bottomley

This is an incorrect statement.  It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out).  It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this).  The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Quoted 3 lines

Incorrect statement how exactly? A JVM can do mmap(), for example, just fine through FileChannel.map() so there's no need for heavy-weight RPC.

Incorrect in that an arbitrary C application can't link to a java API.

mmap and some other messaging (like signals) is just another form of IPC ... the list I gave wasn't exhaustive.

Quoted 6 lines

 Furthermore, the whole discussion is moot anyway as Android runs Dalvik which can be hacked to support whatever communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is hard" nonsense and concentrate on real issues?

I've lost you.  This argument seems to hinge on whether or not you believe that suspend in any form is a solution to the rogue app problem ... whether it's implemented in Java or C is an ancillary issue.

Quoted 16 lines · Pekka Enberg

Quoted 2 lines

Quoted 2 lines

Yup, I don't quite get Arve's argument either. C code can interact with Java code (and vice versa) just fine in userspace.

Quoted 9 lines · James Bottomley

This is an incorrect statement.  It's possible for java to call C via the JNI, even though there are quite a few gotchas that mean not just *any* C code can do it (been there, tripped over some of them, although they were all ultimately ironed out).  It's very difficult for C to call directly into Java without being specially coded because it involves creating and managing a JVM (so in general, arbitrary C code can't do this).  The usual way we do C -> Java is process to process via some intermediary like RPC or Corba or SOAP (or even JSON) ... which gets very messy for a mobile device.

Quoted 3 lines

Incorrect statement how exactly? A JVM can do mmap(), for example, just fine through FileChannel.map() so there's no need for heavy-weight RPC.

Incorrect in that an arbitrary C application can't link to a java API.

mmap and some other messaging (like signals) is just another form of IPC ... the list I gave wasn't exhaustive.

Quoted 6 lines

 Furthermore, the whole discussion is moot anyway as Android runs Dalvik which can be hacked to support whatever communication mechanism is the best choice here.

So can we drop the whole "we need to do it in kernel because Java is hard" nonsense and concentrate on real issues?

I've lost you.  This argument seems to hinge on whether or not you believe that suspend in any form is a solution to the rogue app problem ... whether it's implemented in Java or C is an ancillary issue.

Quoted 4 lines

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Quoted 5 lines

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

Quoted 4 lines

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Quoted 5 lines

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

Quoted 1 line

So provide a C interface to it as well?

We could, but the result would be that any program that needs to block suspend has to be android specific.

Quoted 1 line

So provide a C interface to it as well?

We could, but the result would be that any program that needs to block suspend has to be android specific.

2010/5/26 Peter Zijlstra <[email protected]>:

Quoted 11 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

Quoted 2 lines

So provide a C interface to it as well?

We could, but the result would be that any program that needs to block suspend has to be android specific.

2010/5/26 Peter Zijlstra <[email protected]>:

Quoted 11 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

Quoted 2 lines

So provide a C interface to it as well?

We could, but the result would be that any program that needs to block suspend has to be android specific.

Quoted 9 lines

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

Quoted 9 lines · Arve Hjønnevåg

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

Quoted 9 lines · Arve Hjønnevåg

Quoted 3 lines

With a single suspend manager process that manages the suspend state you can achieve the same goal.

Yes we don't need the /dev interface, but it is useful. Without it any program that needs to block suspend has to make a blocking ipc call into the suspend manager process. Android already does this for java code, but system processes written in C block suspend directly with the kernel since they cannot use the java APIs.

So provide a C interface to it as well?

Surely you can have the java thing have a unix socket or something a C app can talk to. That shouldn't be hard at all.

Or make the suspend manager a C proglet and provide a JNI interface, or whatever.

No, I don't really think it's going to be a small change. The problem is that for the Android people changing user space is very hard, so I don't think this realy is an option, given that they would have to implement it themselves, test it, validate it on multiple different hardware platforms etc. and _then_ resubmit the feature without any guarantee that it will be merged.

No, I don't really think it's going to be a small change. The problem is that for the Android people changing user space is very hard, so I don't think this realy is an option, given that they would have to implement it themselves, test it, validate it on multiple different hardware platforms etc. and _then_ resubmit the feature without any guarantee that it will be merged.

Quoted 1 line · Rafael J. Wysocki

So, basically, you'd prefer to move the entire complexity to user space.

No, just the complexity of the userspace suspend blockers. That was one of the parts of the interface that people objected to, after all.

Quoted 1 line

I'm not sure if that's a big win

It's not a _big_ win, but it is an improvement IMO.

Quoted 3 lines

and I'm not sure anyone is actually going to
implement it (and some drivers would still have to be modified to participate in this framework).

Of course drivers have to be modified. The kernel-layer suspend blockers aren't affected by this proposal, so they still have to be implemented.

Quoted 3 lines

So again, we have a hunch that the goal may be achieved
in a different way, but at this point we'd rather need a _working_ _solution_ (in the form of code one can build and actually use).

It's not very different from what has been submitted, and I think there's little doubt that it could be built and used fairly easily. All we're talking about is removing the userspace suspend-blocker API and the opportunistic workqueue, replacing them with an "opportunistic" entry in /sys/power/state, and setting up a userspace power manager process.

Quoted 3 lines

I don't think it's realistic to expect the Android people to go and redesign their stuff along the lines you've described, because they have a working implementation (in the kernel) that they are satisfied with.

The redesign would be pretty small. The kernel changes relative to what they have submitted are minimal, mostly just removing a few of their additions. Furthermore, we've been told that Android _already_ funnels all its userspace suspend-blocker work through a single process. All that would be needed would be to make that process initiate an opportunistic suspend whenever no userspace suspend blockers were active.

Quoted 6 lines

Now, we can reject their patches, but that's not going to cause any progress to happen, realistically. Quite on the contrary, Android will continue to use wakelocks and Android driver writers will continue to ignore the mainline and the gap between the two kernel lines will only get wider and wider over time.

Quoted 2 lines

And what really is the drawback if we merge the patches? Quite frankly, I don't see any.

You don't seem to appreciate how small a change Dmitry has proposed. Almost all of the suspend-blocker work would remain as in the submitted patches. The only difference is that the userspace API and opportunistic-suspend implementation would be simplified, by moving some of the work out of the kernel.

Quoted 59 lines · Dmitry Torokhov

Quoted 57 lines · Rafael J. Wysocki

Quoted 43 lines · Dmitry Torokhov

Quoted 32 lines · Alan Stern

Quoted 10 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 2 lines

I don't see a big difference between 2 and 3. You can use suspend blockers to handle either.

You can, but they aren't necessary. If 2 were the only reason for suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing mechanism. 3 is perhaps the most important reason for using suspend blockers.

Quoted 5 lines

I do not see why 3 has to be implemented using suspend blockers either. If you are concerned that event gets stuck somewhere in the stack make sure that devices in the stack do not suspend while their queue is not empty. This way if you try opportunistic suspend it will keep failing until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver processes the keystroke and puts it in an input queue. A user process reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend. Since the input queue is empty, there's nothing to stop it. As the first step, userspace is frozen -- before the process has a chance to do anything with the keystroke it just read. As a result, the system stays asleep until something else wakes it up, even though the keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario. Here's how:

Quoted 9 lines

The user process doesn't read the input queue directly; instead it does a select or poll. When it sees there is data in the queue, it first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend blocker is active. The user process can do whatever it wants with the keystroke. When it is finished, it releases the suspend blocker and loops back to the select/poll call.

Quoted 6 lines

What you describe can be done in userspace though, via a "suspend manager" process. Tasks reading input events will post "busy" events to stop the manager process from sending system into suspend. But this can be confined to Android userspace, leaving the kernel as is (well, kernel needs to be modified to not go into suspend with full queues, but that is using existing kernel APIs).

For that to work, you'd have to make the user space suspend manager prevent key-reading processes from emptying the queue before it orders the kernel to put the system to sleep. Otherwise it still is possible that the queue will be emptied right at the moment it writes to /sys/power/state and the scenario described by Alan is going to happen.

Quoted 4 lines

You do exactly the same as what Alan done, but in userspace - poll, post "busy" event to suspend manager, read, process, retract "busy". Basically you still have the suspend blocker, but it is confined to your userspace.

OK, now the question is why this is actually better.

Quoted 59 lines · Dmitry Torokhov

Quoted 57 lines · Rafael J. Wysocki

Quoted 43 lines · Dmitry Torokhov

Quoted 32 lines · Alan Stern

Quoted 10 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 2 lines

I don't see a big difference between 2 and 3. You can use suspend blockers to handle either.

You can, but they aren't necessary. If 2 were the only reason for suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing mechanism. 3 is perhaps the most important reason for using suspend blockers.

Quoted 5 lines

I do not see why 3 has to be implemented using suspend blockers either. If you are concerned that event gets stuck somewhere in the stack make sure that devices in the stack do not suspend while their queue is not empty. This way if you try opportunistic suspend it will keep failing until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver processes the keystroke and puts it in an input queue. A user process reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend. Since the input queue is empty, there's nothing to stop it. As the first step, userspace is frozen -- before the process has a chance to do anything with the keystroke it just read. As a result, the system stays asleep until something else wakes it up, even though the keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario. Here's how:

Quoted 9 lines

The user process doesn't read the input queue directly; instead it does a select or poll. When it sees there is data in the queue, it first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend blocker is active. The user process can do whatever it wants with the keystroke. When it is finished, it releases the suspend blocker and loops back to the select/poll call.

Quoted 6 lines

What you describe can be done in userspace though, via a "suspend manager" process. Tasks reading input events will post "busy" events to stop the manager process from sending system into suspend. But this can be confined to Android userspace, leaving the kernel as is (well, kernel needs to be modified to not go into suspend with full queues, but that is using existing kernel APIs).

For that to work, you'd have to make the user space suspend manager prevent key-reading processes from emptying the queue before it orders the kernel to put the system to sleep. Otherwise it still is possible that the queue will be emptied right at the moment it writes to /sys/power/state and the scenario described by Alan is going to happen.

Quoted 4 lines

You do exactly the same as what Alan done, but in userspace - poll, post "busy" event to suspend manager, read, process, retract "busy". Basically you still have the suspend blocker, but it is confined to your userspace.

OK, now the question is why this is actually better.

Now, we can reject their patches, but that's not going to cause any progress to happen, realistically. Quite on the contrary, Android will continue to use wakelocks and Android driver writers will continue to ignore the mainline and the gap between the two kernel lines will only get wider and wider over time.

And what really is the drawback if we merge the patches? Quite frankly, I don't see any.

Now, we can reject their patches, but that's not going to cause any progress to happen, realistically. Quite on the contrary, Android will continue to use wakelocks and Android driver writers will continue to ignore the mainline and the gap between the two kernel lines will only get wider and wider over time.

And what really is the drawback if we merge the patches? Quite frankly, I don't see any.

Quoted 51 lines · Rafael J. Wysocki

Quoted 43 lines · Dmitry Torokhov

Quoted 32 lines · Alan Stern

Quoted 10 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 2 lines

I don't see a big difference between 2 and 3. You can use suspend blockers to handle either.

You can, but they aren't necessary. If 2 were the only reason for suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing mechanism. 3 is perhaps the most important reason for using suspend blockers.

Quoted 5 lines

I do not see why 3 has to be implemented using suspend blockers either. If you are concerned that event gets stuck somewhere in the stack make sure that devices in the stack do not suspend while their queue is not empty. This way if you try opportunistic suspend it will keep failing until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver processes the keystroke and puts it in an input queue. A user process reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend. Since the input queue is empty, there's nothing to stop it. As the first step, userspace is frozen -- before the process has a chance to do anything with the keystroke it just read. As a result, the system stays asleep until something else wakes it up, even though the keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario. Here's how:

Quoted 9 lines

The user process doesn't read the input queue directly; instead it does a select or poll. When it sees there is data in the queue, it first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend blocker is active. The user process can do whatever it wants with the keystroke. When it is finished, it releases the suspend blocker and loops back to the select/poll call.

Quoted 6 lines

What you describe can be done in userspace though, via a "suspend manager" process. Tasks reading input events will post "busy" events to stop the manager process from sending system into suspend. But this can be confined to Android userspace, leaving the kernel as is (well, kernel needs to be modified to not go into suspend with full queues, but that is using existing kernel APIs).

Quoted 6 lines

For that to work, you'd have to make the user space suspend manager prevent key-reading processes from emptying the queue before it orders the kernel to put the system to sleep. Otherwise it still is possible that the queue will be emptied right at the moment it writes to /sys/power/state and the scenario described by Alan is going to happen.

You do exactly the same as what Alan done, but in userspace - poll, post "busy" event to suspend manager, read, process, retract "busy". Basically you still have the suspend blocker, but it is confined to your userspace.

Quoted 3 lines

Moreover, I don't think it's limited to the input subsystem, because the wakeup events may originate from the network or some other sources and all of them would require similar handling.

Yes, all devices (real or virtual), not only input ones, holding the queues have to refuse suspending for this to work.

Quoted 32 lines · Alan Stern

Quoted 10 lines · Dmitry Torokhov

Quoted 9 lines

Quoted 2 lines

I don't see a big difference between 2 and 3. You can use suspend blockers to handle either.

You can, but they aren't necessary. If 2 were the only reason for suspend blockers, I would say they shouldn't be merged.

Whereas 3, on the other hand, can _not_ be handled by any existing mechanism. 3 is perhaps the most important reason for using suspend blockers.

Quoted 5 lines

I do not see why 3 has to be implemented using suspend blockers either. If you are concerned that event gets stuck somewhere in the stack make sure that devices in the stack do not suspend while their queue is not empty. This way if you try opportunistic suspend it will keep failing until you drained all important queues.

Here's the scenario:

The system is awake, and the user presses a key. The keyboard driver processes the keystroke and puts it in an input queue. A user process reads it from the event queue, thereby emptying the queue.

At that moment, the system decides to go into opportunistic suspend. Since the input queue is empty, there's nothing to stop it. As the first step, userspace is frozen -- before the process has a chance to do anything with the keystroke it just read. As a result, the system stays asleep until something else wakes it up, even though the keystroke was important and should have prevented it from sleeping.

Suspend blockers protect against this scenario. Here's how:

Quoted 9 lines

The user process doesn't read the input queue directly; instead it does a select or poll. When it sees there is data in the queue, it first acquires a suspend blocker and then reads the data.

Now the system _can't_ go into opportunistic suspend, because a suspend blocker is active. The user process can do whatever it wants with the keystroke. When it is finished, it releases the suspend blocker and loops back to the select/poll call.

What you describe can be done in userspace though, via a "suspend manager" process. Tasks reading input events will post "busy" events to stop the manager process from sending system into suspend. But this can be confined to Android userspace, leaving the kernel as is (well, kernel needs to be modified to not go into suspend with full queues, but that is using existing kernel APIs).

This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt.

Quoted 4 lines · Arve Hjønnevåg

This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt.

Patches [1-6/8] applied to suspend-2.6/linux-next

Quoted 6 lines · ext Rafael J. Wysocki

Quoted 4 lines · Arve Hjønnevåg

This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt.

Quoted 1 line

Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of developers had on the other thread, this series is still taken. What's the point in dicussing/reviewing the patches then ?

Quoted 7 lines · Felipe Balbi

Quoted 6 lines · ext Rafael J. Wysocki

Quoted 4 lines · Arve Hjønnevåg

This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt.

Quoted 5 lines

Quoted 1 line

Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of developers had on the other thread, this series is still taken. What's the point in dicussing/reviewing the patches then ?

I don't think the concerns you're referring to can be solved out. Some people just don't like the whole idea and I don't think there's any way we can improve the patches to make them happy. The only "solution" they would be satisfied with would simply be rejecting the feature altogether, although there are no practically viable alternatives known to me.

Quoted 14 lines · Rafael J. Wysocki

Quoted 7 lines · Felipe Balbi

Quoted 6 lines · ext Rafael J. Wysocki

Quoted 4 lines · Arve Hjønnevåg

This patch series adds a suspend-block api that provides the same functionality as the android wakelock api. This version adds a delay before suspending again if no suspend blockers were used during the last suspend attempt.

Quoted 5 lines

Quoted 1 line

Patches [1-6/8] applied to suspend-2.6/linux-next

funny thing is that even without sorting out the concerns plenty of developers had on the other thread, this series is still taken. What's the point in dicussing/reviewing the patches then ?

Quoted 6 lines

I don't think the concerns you're referring to can be solved out. Some people just don't like the whole idea and I don't think there's any way we can improve the patches to make them happy. The only "solution" they would be satisfied with would simply be rejecting the feature altogether, although there are no practically viable alternatives known to me.

I'm not sure who the "some people" you're referring to are, but I'll assume I'm included in that group.

I don't think this is a fair characterization of the objections, nor do I think "rejecting the feature altogether" is the only satisfactory answer. Speaking for myself, I find the idea of being able to suspend while idle a valid objective, and certainly see the usefulness of it for embedded systems. I'm also an owner and user of an Android phone, so I am certainly not out just to make life difficult for Android.

The primary objection is not the end goal, but rather the implementation. In particular, the problematic redefintion of what it means to be idle, or "not doing work that's immediately useful to the user" to use the phrase from the changelog (where "useful" is still not defined.)

This (re)definition completely bypasses all current idle infrastructure based on timers, scheduler, etc. and makes "usefulness" defined in terms of who holds suspend blockers.

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 8 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

Quoted 3 lines

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

Quoted 8 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

Quoted 3 lines

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

Quoted 13 lines · Arve Hjønnevåg

Quoted 11 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 3 lines

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

Quoted 13 lines · Arve Hjønnevåg

Quoted 11 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 3 lines

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

Quoted 13 lines · Arve Hjønnevåg

Quoted 11 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 3 lines

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 13 lines · Arve Hjønnevåg

Quoted 11 lines · Peter Zijlstra

Quoted 6 lines · Rafael J. Wysocki

Quoted 3 lines

This of course will lead to a scattering of suspend blockers into any drivers/subsystems considered "useful", which by looking through current Android kernels is many of them.

That depends on the maintainers of these subsystems, who still have the power to reject requested changes.

So as a scheduler maintainer I'm going to merge a patch that does a suspend_blocker when the runqueue's aren't empty... how about that?

Quoted 3 lines

I don't know if you are serious, since the all the runqueues are never empty while suspending, this would disable opportunistic suspend altogether.

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

So anything relying on (all) userspace solves a different problem.

Quoted 6 lines · Florian Mickler

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?

Quoted 6 lines · Florian Mickler

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

So anything relying on (all) userspace solves a different problem.

So what stops an application from grabbing a suspend blocker?

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

So anything relying on (all) userspace solves a different problem.

Quoted 2 lines

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

Hi Peter!

This was already mentioned in one of these threads.

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

Quoted 11 lines · Florian Mickler

Quoted 2 lines

So why again was this such a great scheme? Go fix your userspace to not not run when not needed.

Hi Peter!

This was already mentioned in one of these threads.

The summary is: The device this kernel is running on dosn't want to (or can) rely on userspace to save power. This is because it is an open system, without an app-store or the like. Everyone can run what he wants.

I don't see this as a valid point. Everyone can run a different kernel where nothing will just work. Are you aiming protection against that as well?

~Vitaly

This is not "protection". This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek)

This is not "protection". This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek)

Quoted 3 lines · Florian Mickler

This is not "protection". This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;)

~Vitaly

Quoted 3 lines · Florian Mickler

This is not "protection". This is functioning properly in a real world scenario. Why would the user change the kernel, if the device would be buggy after that? (Except maybe he is a geek)

Hmm... Why would the user continue to use the program if it slows down his device and sucks the battery as a vampire (Except maybe he's a moron)? ;)

~Vitaly

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

Hi,

Quoted 4 lines · ext Florian Mickler

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

and that's enough to push hacks into the kernel ? I don't think so. Do it like apple and prevent multi-tasking for any non-apple applications :-p

It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other.

So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource "power".

It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other.

So merging this patch set will allow android to continue
their work _on mainline_ while everybody else can continue as before.

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

But look at it this way: Suspend blockers are a way for the kernel to make user space programs accountable for using the resource "power".

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like).

Quoted 2 lines

This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like).

You would do better to concentrate on technical issues that the assignment of malicious intent to other parties.

Alan

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Quoted 2 lines

This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like).

You would do better to concentrate on technical issues that the assignment of malicious intent to other parties.

Alan

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

This is a _big_ plus for attracting 3rd party programs. (And of course the thing you don't like).

It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So you should be happy there.

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel.

It really comes down to a policy decision by the distribution maker. And I don't think kernel upstream should be the one to force one way or the other. So merging this patch set will allow android to continue their work _on mainline_ while everybody else can continue as before.

All points about the impact on the kernel have already been raised. So you should be happy there.

Nonetheless, I really think the kernel needs to allow for the android way of power saving. It misses out on a big feature and a big user-base if not.

Also I expect there to be synergies between android development and mainline kernel development _only_ if android development can use mainline kernel.

Quoted 12 lines · On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <[email protected]> wrote:

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Quoted 6 lines

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

Quoted 22 lines · Florian Mickler

Quoted 12 lines · On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <[email protected]> wrote:

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Quoted 6 lines

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

Quoted 4 lines

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

Provide the developers and users with tools.

Notify the users that their phone is using power at an unadvised rate due to proglet $foo.

Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue.

The kernel can not win if it does not try to integrate any use of it.

The kernel can not win if it does not try to integrate any use of it.

Quoted 1 line · Florian Mickler

The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away screaming.

We most certainly do not want to integrate _any_ use.

Quoted 1 line · Florian Mickler

The kernel can not win if it does not try to integrate any use of it.

If we'd integrate every patch that came to lkml, you'd run away screaming.

We most certainly do not want to integrate _any_ use.

Quoted 22 lines · Florian Mickler

Quoted 12 lines · On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <[email protected]> wrote:

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Quoted 6 lines

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

Quoted 4 lines

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

Provide the developers and users with tools.

Notify the users that their phone is using power at an unadvised rate due to proglet $foo.

Also, if you can integrate into the development environment and provide developers instant feedback on suckage of their app they can react and fix before letting users run into the issue.

Quoted 12 lines · On Wed, 26 May 2010 15:29:32 +0300 Felipe Balbi <[email protected]> wrote:

hi,

Quoted 3 lines · ext Florian Mickler

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

What I find ridiculous is the assumption that kernel should provide good power management even for badly written applications. They should work, of course, but there's no assumption that the kernel should cope with those applications and provide good battery usage on those cases.

Quoted 6 lines

You can install and run anything on the device, and they will work as they should (they will be scheduled and will be processed) but you can't expect the kernel to prevent that application from waking up the CPU every 10 ms simply because someone didn't think straight while writting the app.

But then someone at the user side has to know what he is doing.

I fear, if you target mass market without central distribution channels, you can not assume that much.

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

Quoted 7 lines · Florian Mickler

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way.

~Vitaly

Quoted 7 lines · Florian Mickler

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

You almost always need to "hack" the mainline software for a production system. So do it here as well. Make sure the hack is well isolated and local. You can even submit it to the mainline, better as a configuration option, _unless_ it is a *framework* that provokes writing code in an ugly and unsafe way.

~Vitaly

I don't think that the in-kernel suspend block is a bad idea.

You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not.

Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a "suspend as soon as possible" semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away).

I don't think that the in-kernel suspend block is a bad idea.

You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not.

Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a "suspend as soon as possible" semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away).

Quoted 4 lines · Florian Mickler

I don't think that the in-kernel suspend block is a bad idea.

You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not.

That's not how it works. Drivers aren't supposed to abort unconditional suspend -- not without a really good reason (for example, the device received a wakeup event before it was fully suspended). In short, suspends should be considered to be _always_ possible.

Quoted 5 lines

Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a "suspend as soon as possible" semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away).

That's different. Suspend blockers could block (not abort!) regular suspends, just as they do opportunistic suspends.

But why should they? I mean, if userspace wants to initiate a suspend that is capable of being blocked by a kernel suspend blocker, then all it has to do is initiate an opportunistic suspend instead of a normal suspend.

Alan Stern

Quoted 4 lines · Florian Mickler

I don't think that the in-kernel suspend block is a bad idea.

You could probably use the suspend-blockers unconditionally in the suspend framework to indicate if a suspend is possible or not.

That's not how it works. Drivers aren't supposed to abort unconditional suspend -- not without a really good reason (for example, the device received a wakeup event before it was fully suspended). In short, suspends should be considered to be _always_ possible.

Quoted 5 lines

Regardless of opportunistic suspend or not. This way, you don't have to try-and-fail on a suspend request and thus making suspending potentially more robust or allowing for a "suspend as soon as possible" semantic (which is probably a good idea, if you have to grab your laptop in a hurry to get away).

That's different. Suspend blockers could block (not abort!) regular suspends, just as they do opportunistic suspends.

But why should they? I mean, if userspace wants to initiate a suspend that is capable of being blocked by a kernel suspend blocker, then all it has to do is initiate an opportunistic suspend instead of a normal suspend.

Alan Stern

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical. (Much work.)

Converting a driver to using any constraint-API would require analysing
what makes a driver refuse suspending in the old suspend handler and
then specify any "no suspend" (or whatever) constraint before those
conditions arise and clearing of the constraints when it is no longer critical. (Much work.)

Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any "no suspend" (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.)

Converting a driver to using any constraint-API would require analysing what makes a driver refuse suspending in the old suspend handler and then specify any "no suspend" (or whatever) constraint before those conditions arise and clearing of the constraints when it is no longer critical. (Much work.)

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

Quoted 15 lines

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

Quoted 6 lines

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

I completely agree.

We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap!

That's not a solution, that's just capitulation.

It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea.

Quoted 15 lines

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

Quoted 6 lines

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

I completely agree.

We have already proven that the social pressure on crappy applications works. When NOHZ was merged into the kernel we got no effect at all because a big percentage of user space applications just used timers at will and without any thoughts, also it unveiled busy polling and other horrible coding constructs. So what happened ? Arjan created powertop which lets the user analyse the worst offenders in his system. As a result the offending apps got fixed rapidly simply because no maintainer wanted to be on top of the powertop sh*tlist.

In the mobile app space it's basically the same problem. Users can influence the app writers simply by voting and setting up public lists of apps which are crappy or excellent. All it needs is a nice powertop tool for the phone which allows the users to identify the crap on their phones. That provides much more incentive - especially for commercial players - to fix their crappy code.

Adding that sys_try_to_fix_crappy_userspace_code() API to the kernel is just counter productive as it signals to the app provider: Go ahead, keep on coding crap!

That's not a solution, that's just capitulation.

It's absurd that some folks believe that giving up the most efficient tool to apply pressure to crappy app providers is a good idea.

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

		setpidle(getpid(), something);
		exec()

where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone.

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

Alan

Quoted 3 lines

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1])

Quoted 3 lines

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1])

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

That's backwards.

Quoted 1 line · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:

Quoted 6 lines

Quoted 4 lines

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

That's backwards.

I think that's the point of it.

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

Quoted 3 lines

Quoted 1 line

That's backwards.

I think that's the point of it.

Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again.

Quoted 10 lines · On Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

That's backwards.

I think that's the point of it.

Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer.

Cheers,
Flo

Quoted 10 lines · On Wed, 26 May 2010 17:45:00 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

That's backwards.

I think that's the point of it.

Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again.

I'm sorry if I offend you. I indeed read Alan's emails. It's just they have more content than yours. So it takes longer.

Cheers,
Flo

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

Quoted 3 lines

Quoted 1 line

That's backwards.

I think that's the point of it.

Apparently, and you're not accepting that we're telling you we think its a singularly bad idea. Alan seems to have the skill to clearly explain why, I suggest you re-read his emails again.

Quoted 1 line · On Wed, 26 May 2010 17:15:47 +0200 Peter Zijlstra <[email protected]> wrote:

On Wed, 2010-05-26 at 17:11 +0200, Florian Mickler wrote:

Quoted 6 lines

Quoted 4 lines

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

That's backwards.

I think that's the point of it.

Quoted 4 lines · Florian Mickler

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

That's backwards.

If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

If you don't want to suspend while
looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android

userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

in the first place.

How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1])

p.s.:
dmk@schatten /usr/src/linux $ grep -r "setpidle" .

I'm not saying that your argument is not valid. But why don't you look at suspend blockers as a contract between userspace and kernelspace? An Opt-In to the current guarantees the kernel provides in the non-suspend case.

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android

userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

in the first place.

How does this address the loss of wakeup events while using suspend? (For example the 2 issues formulated by Alan Stern in [1])

p.s.:
dmk@schatten /usr/src/linux $ grep -r "setpidle" .

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

in the first place.

This "optionally being badly written, who cares?" is a new feature the kernel can provide to applications.

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ?

Alan

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ?

Alan

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Quoted 6 lines · On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool <[email protected]> wrote:

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Quoted 4 lines

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org.

So why don't we do what we always do? Improve existing interfaces step by step?

Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation.

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool <[email protected]> wrote:

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Quoted 8 lines

Quoted 4 lines

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org.

No, it's not a historical mistake. It's a technical decision _NOT_ to merge crap. If we would accept every crappy patch which gets shipped in large quantities as a defacto part of the kernel we would have a completely unmaintainable mess since years.

Quoted 2 lines

So why don't we do what we always do? Improve existing interfaces step by step?

Exactly, that's what we are going to do. We improve and extend existing interfaces step by step, but not by creating a horrible and unmaintainable mess in the frist place which we can never get rid of anymore.

Quoted 4 lines

Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation.

Nobody prevents you to sit down and start with a prove of concept implementation.

Thanks,

tglx

Quoted 9 lines · Florian Mickler

Quoted 6 lines · On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool <[email protected]> wrote:

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Quoted 8 lines

Quoted 4 lines

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org.

No, it's not a historical mistake. It's a technical decision _NOT_ to merge crap. If we would accept every crappy patch which gets shipped in large quantities as a defacto part of the kernel we would have a completely unmaintainable mess since years.

Quoted 2 lines

So why don't we do what we always do? Improve existing interfaces step by step?

Exactly, that's what we are going to do. We improve and extend existing interfaces step by step, but not by creating a horrible and unmaintainable mess in the frist place which we can never get rid of anymore.

Quoted 4 lines

Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation.

Nobody prevents you to sit down and start with a prove of concept implementation.

Thanks,

tglx

Quoted 6 lines · On Wed, 26 May 2010 22:03:37 +0200 Vitaly Wool <[email protected]> wrote:

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

Quoted 4 lines

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Because quite frankly, for a good part of linux users, suspend blockers is already in the kernel. It's just an historical mistake that they are not in the linux kernel's hosted on kernel.org.

So why don't we do what we always do? Improve existing interfaces step by step?

Top Down approaches fail from time to time. Also it is not clear, that that proposed interface works for the use cases. This has to be proven by providing an implementation.

Quoted 3 lines · Florian Mickler

Your approach definitely sounds better than the current solution. What about mapping suspend blocker functionality later on, when this interface exists, on to this new approach and deprecating it?

What about coming back after some while with the appropriate solution when it's ready instead of stubbornly pushing crap?

~Vitaly

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ?

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Even if you believe the kernel should be containing junk the model that works and is used for everything else is resource management. Not giving various tasks the ability to override rules, otherwise you end up needing suspend blocker blockers next week.

A model based on the idea that a task can set its desired wakeup behaviour *subject to hard limits* (ie soft/hard process wakeup) works both for the sane system where its elegantly managing hard RT, and for the crud where you sandbox it to stop it making a nasty mess.

Do we even need a syscall or will adding RLIMIT_WAKEUP or similar do the trick ?

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Florian,

Quoted 4 lines · Florian Mickler

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

Quoted 1 line

This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already.

So what the kernel needs to know to make better decisions are things like:

- how much slack can timers have (exisiting interface)

- how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to make better decisions versus power states, grouping timers, race to idle and other things which influence the power consumption based on the hardware you are running on.

Quoted 8 lines

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

Quoted 4 lines

in the first place.

This "optionally being badly written, who cares?" is a new feature the kernel can provide to applications.

It's a misfeature which the kernel should not provide at all. It sends out the completely wrong message: Hey, we can deal with your crappy code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space, it's completely backwards and will backfire in no time.

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Thanks,

tglx

Quoted 2 lines

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it.

drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on?

Quoted 1 line

- how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most applications. I see this as an orthogonal thing (i.e. not affecting this merge).

True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users.

We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs)

Alan

We now have suggestions how to do the job properly so the right thing is probably to go and explore those suggestions not merge crap.

Merging crap won't help anyway. The rest of the kernel community can still simply stonewall those interfaces, and a volunteer community has ways of dealing with abuse of process, notably by simply not getting around to, or implementing things directly contrary to the crap bits.

So it's not even in the interest of people to play political games. Even if you get away with in the short term the people who rely on the junk will end up out on a limb and holding the baby when the crap hits the fan (see reiserfs)

Alan

I'm not interested in "abusing processes". I just think, this is in limbo for too long already.
Just decide something. One way or the other. The world will continue.

I'm not interested in "abusing processes". I just think, this is in limbo for too long already.
Just decide something. One way or the other. The world will continue.

Quoted 2 lines

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it.

drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on?

Quoted 1 line

- how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most applications. I see this as an orthogonal thing (i.e. not affecting this merge).

True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users.

Quoted 5 lines · On Wed, 26 May 2010 19:22:16 +0200 (CEST) Thomas Gleixner <[email protected]>…

Quoted 4 lines · Florian Mickler

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

Quoted 7 lines

Quoted 1 line

This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it.

Yeah, but a user can't say: "I don't
know programming, but I had this idea. Here try it out." to his friend. Because his friends phone then will crap out.

This is a negative. The phone just doesn't work well.

A knowledgeable programmer is able to do extra work to enable specific guarantees. A dummy-throw-away-programmer doesn't want to do any extra work.

Quoted 3 lines

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it.

Quoted 6 lines

Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already.

This is true. Nonetheless, in my opinion, implementing the "backwards approach" in any form (suspend blockers or some other sort of "sane" interface) is necessary in the long run. I also believe that Alan's approach is the more flexible one. But I'm not in a position to judge on this.

If it really is better and superior, I think userland will switch over to it, as soon as it is possible to do it. The impact to the drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on?

Quoted 4 lines

So what the kernel needs to know to make better decisions are things like:

- how much slack can timers have (exisiting interface)

I liked this idea of Arjan, to give some applications infinite timer slack. But I don't know if it can made work in a "dummy proof" way. (I.e. it is too complicated to get it right in general, except for the "infinity" or not kind of tuning)

Quoted 1 line

- how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most

applications. I see this as an orthogonal thing (i.e. not affecting this merge).

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users.

Quoted 5 lines · On Wed, 26 May 2010 19:22:16 +0200 (CEST) Thomas Gleixner <[email protected]>…

Quoted 4 lines · Florian Mickler

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

Quoted 7 lines

Quoted 1 line

This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it.

Yeah, but a user can't say: "I don't
know programming, but I had this idea. Here try it out." to his friend. Because his friends phone then will crap out.

This is a negative. The phone just doesn't work well.

A knowledgeable programmer is able to do extra work to enable specific guarantees. A dummy-throw-away-programmer doesn't want to do any extra work.

Quoted 3 lines

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

I don't think this is a defect in the approach but the point of it.

Quoted 6 lines

Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already.

This is true. Nonetheless, in my opinion, implementing the "backwards approach" in any form (suspend blockers or some other sort of "sane" interface) is necessary in the long run. I also believe that Alan's approach is the more flexible one. But I'm not in a position to judge on this.

If it really is better and superior, I think userland will switch over to it, as soon as it is possible to do it. The impact to the drivers code is needed anyway. What looses the kernel by implementing suspend blockers, and later a more finegrained approach and mapping the userspace part of suspend blockers on that finegrained approach later on?

Quoted 4 lines

So what the kernel needs to know to make better decisions are things like:

- how much slack can timers have (exisiting interface)

I liked this idea of Arjan, to give some applications infinite timer slack. But I don't know if it can made work in a "dummy proof" way. (I.e. it is too complicated to get it right in general, except for the "infinity" or not kind of tuning)

Quoted 1 line

- how much delay of wakeups is tolerated (missing interface)

Doesn't solve the segregation problem and is probably overkill for most

applications. I see this as an orthogonal thing (i.e. not affecting this merge).

Quoted 3 lines

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

True. But I wouldnt say, that it is the linux kernel who should force this politics onto its users.

Florian,

Quoted 4 lines · Florian Mickler

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

Quoted 1 line

This is an option which they currently don't have.

Wrong. A well coded power aware application is very well able to express that in various ways already today. Admittedly it's far from perfect, but that can be fixed by adding interfaces which allow the power aware coder to express the requirements of his application actively, not by avoiding it.

suspend blockers are completely backwards as they basically disable the kernels ability to do resource management.

Also they enforce a black and white scheme (suspend or run) on the kernel which is stupid, as there are more options to efficiently save power than those two. While current android devices might not provide them, later hardware will have it and any atom based device has them already.

So what the kernel needs to know to make better decisions are things like:

- how much slack can timers have (exisiting interface)

- how much delay of wakeups is tolerated (missing interface)

and probably some others. That information would allow the kernel to make better decisions versus power states, grouping timers, race to idle and other things which influence the power consumption based on the hardware you are running on.

Quoted 8 lines

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

Quoted 4 lines

in the first place.

This "optionally being badly written, who cares?" is a new feature the kernel can provide to applications.

It's a misfeature which the kernel should not provide at all. It sends out the completely wrong message: Hey, we can deal with your crappy code, keep on coding that way.

While this seems to sound cool to certain people in the mobile space, it's completely backwards and will backfire in no time.

The power efficiency of a mobile device is depending on a sane overall software stack and not on the ability to mitigate crappy software in some obscure way which is prone to malfunction and disappoint users.

Thanks,

tglx

On the other hand, applications can say, they don't need that much power and userspace guaranties and not take a suspend blocker.

This is an option which they currently don't have.

I don't think opportunistic suspend is a policy decision by the kernel. it is something new. Something which currently only the android userspace implements / supports. If you don't want to suspend while looking at the bouncing-cow, you have to take a suspend blocker and make yourself a user-visible power-eater, or don't do

echo "opportunistic" > /sys/power/policy

in the first place.

This "optionally being badly written, who cares?" is a new feature the kernel can provide to applications.

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends. What you are essentially arguing for is for the kernel to disobey the userspace. It's as ridiculous (albeit usually less damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

		setpidle(getpid(), something);
		exec()

where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone.

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

Alan

[1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. "Static" simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states)

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

What you are essentially arguing for is for the
kernel to disobey the userspace.

It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

               setpidle(getpid(), something);
               exec()

where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone.

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. "Static" simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

What you are essentially arguing for is for the
kernel to disobey the userspace.

It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app can't have meant it, I'll put your document soemwhere else"

The whole API feels wrong to me. It's breaking rule #1 of technology "You cannot solve a social problem with technology". In this case you have a social/economic problem which is crap code. You solve it with an economics solution - creative incentives not to produce crap code like boxes that keep popping up saying "App XYZ is using all your battery" and red-amber-green powermeter scores in app stores.

That said if you want technical mitigation I think it makes more sense if you look at it from a different starting point. The starting point being this: We have idling logic in the kernel and improving this helps everyone. What is needed to improve the existing logic ?

- You don't know which processes should be ignored for the purpose of suspend (except for kernel threads) and there is no way to set this

- You don't know whether a move from a deep idle to a 'suspend' (which is just a really deep idle in truth anyway) might break wakeups requirements because a device has wake dependencies due to hardware design (eg a port that has no electronics to kick the box out of suspend into running). This is a problem we have already. [1]

That maps onto two existing ideas

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

               setpidle(getpid(), something);
               exec()

where 'something' is a value with meaning to both user space and to the existing idling logic in the kernel that basically says to what extent it is permitted to block idling/suspend. That also seems to tie into some of the realtime + idle problems. This I think deals with Kevin Hillman's thoughts on dealing with untrustworthy app code more cleanly and avoids the need for userspace hackery like the blocker API.

And an entirely in kernel API where device drivers can indicate that in their current situation they require that the power level doesn't drop below some limit unless user requested. This is really important because the platform vendor of the phone/pda/tablet whatever effectively owns the kernel - so it's *their* problem, *their* control, *their* hardware and they can make it work as best for the device. Best of all it means its all free software stuff so if the vendor screws up you can still fix your phone.

Implementation-wise it probably ties into setpidle, its simply that a task has a pair of idle values, a dynamic one and a base one, the dynamic one being the base one but updatable temporarily by drivers.

Alan
--

[1] Note I disagree with Kevin here on static/dynamic power management. There are IMHO two types of PM but they are 'user invoked' and 'automatic'. "Static" simply means it's not been made fast enough yet but its just a policy divide dependant on the users 'acceptable' resume time (which for hard RT may just as well rule out some more usual power states)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 8 lines · Alan Cox

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

Quoted 3 lines

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends.

Quoted 2 lines

What you are essentially arguing for is for the
kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore.

Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it.

Quoted 2 lines

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response.

What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel?

Quoted 13 lines · On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 11 lines · Alan Cox

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

Quoted 2 lines

We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends.

This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable.

My app simply should not have to know this sort of crap, that's the whole point of an OS.

Quoted 7 lines

Quoted 2 lines

What you are essentially arguing for is for the
kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win.

Quoted 6 lines

Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it.

Opportunistic suspend isn't special. Suspend is just a very deep idle. In

fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states.

User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy.

Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with.

Quoted 8 lines

Quoted 2 lines

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response.

But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends.

Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly.

So what are expressing

'I am using device 'screen' please keep it live'  (which may or may not block suspend - see OLPC). I guess your display server and kernel support manage this bit.

'I want the photo to appear in a resonable timescale'  (latency). It's not a suspend question - an imaginary non suspend idle mode with a 20 second latency would be just as annoying yes ?

At the moment we have a very real bigger problem that your problem is part of.

- Hard real time people want to be able to limit the CPU sleeping behaviour based upon what tasks are running

- Certain gaming types want their boxes to be good power citizens except when committing digital mass murder. Right now that involves wrapping the game in a script with bits occurring as root and that generally breaks if the game crashes so the script doesn't run nicely on exit

- Virtual machine people desperately want to see latency data to help schedule stuff in a power efficient manner.  In a virtual machine environment its vital information about how you schedule a virtual machine, whether now is a good time to live migrate it and how best to optimise power/performance on the server end.

- Some drivers want to constrain idling because they know platform/hardware stuff the core power management code doesn't (eg serial ports at high speed). We want that expressed in a way that keeps the power management code clean of such device knowledge

Now I don't care if we have an elegant kernel interface and Android uses it as a big hammer - if that makes Android work well everyone can be happy. What I don't want is to have a big hammer when it doesn't solve the underlying big picture problem for everyone.

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those later
- Suspend is just a power state

How does that fit your model and vision ?

Quoted 2 lines

What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to support the user API and blissfully ignore it. Applications will ask for

various latency guarantees and of course always get them. The apps will be portable, the device will be offering it's best behaviour and everyone will be happy.

If your device only supports full on and suspend I don't see why opportunistic suspend couldn't be provided assuming sufficient wakeup support was present. It won't be the most exciting power management policy to write but it's perfectly doable and the apps again will not need recoding to handle it.

The latency goal data is also priceless for another consumer - in a virtual machine environment its vital information about how you schedule a virtual machine, whether now is a good time to live migrate it and how best to optimise power/performance on the server end.

Alan

Quoted 13 lines · On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 11 lines · Alan Cox

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

Quoted 2 lines

We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends.

This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable.

My app simply should not have to know this sort of crap, that's the whole point of an OS.

Quoted 7 lines

Quoted 2 lines

What you are essentially arguing for is for the
kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win.

Quoted 6 lines

Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it.

Opportunistic suspend isn't special. Suspend is just a very deep idle. In

fact some of the low power states on processors look little different to suspend - the OS executes a whole pile of CPU state saving and cache flushing. It might be a hardware state machine, it might be buried in firmware or it might be quite explicit (eg mrst). So we already have differing degrees of doing additional work in different states.

User triggered suspend is a bit special in that the user is usually right in that case to override the power management policy.

Note I'm not suggesting we run off and restructure all our power management code to take this view right now. I'm suggesting we need a clean 'opportunistic suspend is not special' view by user space. How the kernel handles this is addressible later without app breakage, but only if we get the interface wrong to begin with.

Quoted 8 lines

Quoted 2 lines

Sandboxing/Resource Limits: handling apps that can't be trusted. So the phone runs the appstore code via something like

Sandboxing is problematic on Android since there are a lot of cross process dependencies. When a call comes in I don't know where the name and picture to display comes from. With suspend blockers we block suspend when we get notified that we have an incoming call and we can call into any process and get a response.

But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends.

Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly.

So what are expressing

'I am using device 'screen' please keep it live'  (which may or may not block suspend - see OLPC). I guess your display server and kernel support manage this bit.

'I want the photo to appear in a resonable timescale'  (latency). It's not a suspend question - an imaginary non suspend idle mode with a 20 second latency would be just as annoying yes ?

At the moment we have a very real bigger problem that your problem is part of.

- Hard real time people want to be able to limit the CPU sleeping behaviour based upon what tasks are running

- Certain gaming types want their boxes to be good power citizens except when committing digital mass murder. Right now that involves wrapping the game in a script with bits occurring as root and that generally breaks if the game crashes so the script doesn't run nicely on exit

- Virtual machine people desperately want to see latency data to help schedule stuff in a power efficient manner.  In a virtual machine environment its vital information about how you schedule a virtual machine, whether now is a good time to live migrate it and how best to optimise power/performance on the server end.

- Some drivers want to constrain idling because they know platform/hardware stuff the core power management code doesn't (eg serial ports at high speed). We want that expressed in a way that keeps the power management code clean of such device knowledge

Now I don't care if we have an elegant kernel interface and Android uses it as a big hammer - if that makes Android work well everyone can be happy. What I don't want is to have a big hammer when it doesn't solve the underlying big picture problem for everyone.

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those later
- Suspend is just a power state

How does that fit your model and vision ?

Quoted 2 lines

What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to support the user API and blissfully ignore it. Applications will ask for

various latency guarantees and of course always get them. The apps will be portable, the device will be offering it's best behaviour and everyone will be happy.

If your device only supports full on and suspend I don't see why opportunistic suspend couldn't be provided assuming sufficient wakeup support was present. It won't be the most exciting power management policy to write but it's perfectly doable and the apps again will not need recoding to handle it.

The latency goal data is also priceless for another consumer - in a virtual machine environment its vital information about how you schedule a virtual machine, whether now is a good time to live migrate it and how best to optimise power/performance on the server end.

Alan

2010/5/26 Alan Cox <[email protected]>:

Quoted 19 lines

Quoted 15 lines · On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 11 lines · Alan Cox

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends.

Quoted 4 lines

This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from idle and still wake up for the next timer or interrupt, then do that. Suspend blockers should have not effect on this.

Quoted 4 lines

My app simply should not have to know this sort of crap, that's the whole point of an OS.

Most apps does not have to know about this with opportunistic suspend either. If the user is interacting with the device, we don't suspend. If your apps needs to run when the user is not interacting with the device, then you can block suspend.

Quoted 22 lines

Quoted 7 lines

Quoted 2 lines

What you are essentially arguing for is for the
kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win.

Quoted 6 lines

Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it.

Quoted 1 line

Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular timers stop, and only specially marked wakeup events can bring the system back to the normal state.

Quoted 6 lines

But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends.

Quoted 3 lines

Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly.

I don't think a latency api is the right way to express this since the only latency values we would use is minimal-latency and any-latency. What we are expressing is that this works need to happen now, even if the user is not currently interacting with the device.

Quoted 13 lines

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those later
- Suspend is just a power state

Quoted 2 lines

How does that fit your model and vision ?

We have two main modes of operation. The user is interacting with the device and tasks and timers should run as requested. And, the user is not interacting with the device and the device should enter (and stay in) low power states regardless of running tasks and timers. Since some events (e.g. incoming phone call, alarm clock) will may cause the user to start interacting with the device, they need special treatment. A per thread latency api does not work for us. A global latency api could work, but since would only use minimal latency or any latency this seem like overkill. Also, with a global latency api, how do I know it the requested latency is meant to improve the experience while the user is interacting with the app, or if it meant the app needs to run when the user is not interacting with the device.

Quoted 5 lines

Quoted 2 lines

What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to support the user API and blissfully ignore it. Applications will ask for

I don't think you understood what I asked. Currently most x86 systems can enter much lower power states from suspend than they can from idle. Are you suggesting that we remove suspend support from Linux and try to enter the same power states on x86 from idle that we now enter from suspend? It is not clear to me if this is possible.

2010/5/26 Alan Cox <[email protected]>:

Quoted 19 lines

Quoted 15 lines · On Wed, 26 May 2010 15:30:58 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 11 lines · Alan Cox

Quoted 7 lines

Really, what are you getting at? Do you deny that there are programs, that prevent a device from sleeping? (Just think of the bouncing cows app)

And if you have two kernels, one with which your device is dead after 1 hour and one with which your device is dead after 10 hours. Which would you prefer? I mean really... this is ridiculous.

The problem you have is that this is policy. If I have the device wired to a big screen and I want cows bouncing on it I'll be most upset if instead it suspends.

We never suspend when the screen is on. If the screen is off, I would not be upset if it suspends.

Quoted 4 lines

This is policy and platform specific. The OLPC can suspend with the screen on. Should I write my app to know about this once for Android and once for OLPC (and no doubt once for Apple). In the OLPC case cows could indeed suspend to RAM between frames if the wakeup time was suitable.

Are you still talking about Linux suspend? If you can enter S3 from idle and still wake up for the next timer or interrupt, then do that. Suspend blockers should have not effect on this.

Quoted 4 lines

My app simply should not have to know this sort of crap, that's the whole point of an OS.

Most apps does not have to know about this with opportunistic suspend either. If the user is interacting with the device, we don't suspend. If your apps needs to run when the user is not interacting with the device, then you can block suspend.

Quoted 22 lines

Quoted 7 lines

Quoted 2 lines

What you are essentially arguing for is for the
kernel to disobey the userspace.

No I'm not. User-space asked the kernel to suspend when possible. Suspend is an existing kernel feature. All opportunistic suspend adds is the ability to use it safely when there are wakeup event you cannot afford to ignore.

Don't get me wrong - opportunistic suspend isn't the problem. Suspend blockers are - or more precisely - the manner in which they express intent from userspace. Opportunistic suspend is wonderful stuff for all sorts of things and if it persuades people like netbook manufacturers to think harder, and Linux driver authors to optimise their suspend/resume paths we all win.

Quoted 6 lines

Our actual stating point is this: Some systems can only enter their lowest power state from suspend. So we added an api that allowed us to use suspend without loosing wakeup events. Since suspending also improves our battery life on platforms that enter the same power state from idle and suspend and we already have a way to safely use suspend, we would be crazy not to use it.

Quoted 1 line

Opportunistic suspend isn't special. Suspend is just a very deep idle. In

Suspend as it is currently implemented in Linux is special. Regular timers stop, and only specially marked wakeup events can bring the system back to the normal state.

Quoted 6 lines

But you can express user suspend blocking in this manner. Your call incoming code would say 'I want good latency'. As someone needs good latency the box won't suspend. If your approach is to start with an initial 'anyone can set a low latency we don't care' then anyone can block suspends.

Quoted 3 lines

Equally your call handling example is about latency not about suspend. You want the phone to stay on, to fetch a picture and display it promptly.

I don't think a latency api is the right way to express this since the only latency values we would use is minimal-latency and any-latency. What we are expressing is that this works need to happen now, even if the user is not currently interacting with the device.

Quoted 13 lines

So my working position is summarised thusly

- Supporting Android needs well good
- Opportunistic suspend good
- Manner in which interface is expressed to userspace bad
- Latency constraint interface would be better
- Your existing behaviour can be implemented by a simplistic use of a latency constraint interface
- We can fix a pile of other directly connected things at the same time
- Implementation internals I care far less about because we can fix those later
- Suspend is just a power state

Quoted 2 lines

How does that fit your model and vision ?

We have two main modes of operation. The user is interacting with the device and tasks and timers should run as requested. And, the user is not interacting with the device and the device should enter (and stay in) low power states regardless of running tasks and timers. Since some events (e.g. incoming phone call, alarm clock) will may cause the user to start interacting with the device, they need special treatment. A per thread latency api does not work for us. A global latency api could work, but since would only use minimal latency or any latency this seem like overkill. Also, with a global latency api, how do I know it the requested latency is meant to improve the experience while the user is interacting with the app, or if it meant the app needs to run when the user is not interacting with the device.

Quoted 5 lines

Quoted 2 lines

What about platforms that currently cannot enter low power states from idle? Do you remove suspend support from the kernel?

I would actually expect a system that can't do any low power states to support the user API and blissfully ignore it. Applications will ask for

I don't think you understood what I asked. Currently most x86 systems can enter much lower power states from suspend than they can from idle. Are you suggesting that we remove suspend support from Linux and try to enter the same power states on x86 from idle that we now enter from suspend? It is not clear to me if this is possible.

Opportunistic suspends are okay.

The proposed userspace API is too Android-specific.

Opportunistic suspends are okay.

The proposed userspace API is too Android-specific.

Quoted 4 lines · Alan Stern

Opportunistic suspends are okay.

The proposed userspace API is too Android-specific.

I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant.

Quoted 6 lines · On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Alan Stern

Opportunistic suspends are okay.

The proposed userspace API is too Android-specific.

Quoted 2 lines

I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant.

Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too)

Quoted 6 lines · On Thu, 27 May 2010 17:09:16 +0200 Peter Zijlstra <[email protected]> wrote:

Quoted 4 lines · Alan Stern

Opportunistic suspends are okay.

The proposed userspace API is too Android-specific.

Quoted 2 lines

I would argue opportunistic suspends are not ok, and therefore the proposed API is utterly irrelevant.

Assuming you are happy that opportunistically entering C6 and the like is ok via ACPI can you explain why you have a problem with opportunistic suspend and why it is different to a very deep sleep CPU state such as we have now (and which on many embedded platforms we deal with *is* sleeping external devices too)