Suspend block api (version 8)

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

Quoted 87 lines · James Bottomley

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

Quoted 9 lines

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

True.

The following is what I think I'll work on this weekend. (hopefully have some sort of patch that at least compiles...)

Changes to pm_qos to enable "wakelock" or "suspend blocker" support:

Requirements:
1) atomic context support.
2) make updating request fast enough for hot path users.
3) Add a request class for "interactive_suspend", this particular request has a dynamic range of 1 (its 0 or 1). If zero then ok to auto suspend, if 1 then only user driven suspend. Whenever the aggregate request changes value the registered notifiers are called.

Implementation:
* change api to have caller allocated the qos request structures. (solve the kalloc issue)
* add plist use for constraint classes with hash-able dynamic ranges

Quoted 115 lines · mark gross

Quoted 87 lines · James Bottomley

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

Quoted 9 lines

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

True.

The following is what I think I'll work on this weekend. (hopefully have some sort of patch that at least compiles...)

Changes to pm_qos to enable "wakelock" or "suspend blocker" support:

Requirements:
1) atomic context support.
2) make updating request fast enough for hot path users.
3) Add a request class for "interactive_suspend", this particular request has a dynamic range of 1 (its 0 or 1). If zero then ok to auto suspend, if 1 then only user driven suspend. Whenever the aggregate request changes value the registered notifiers are called.

Quoted 4 lines

Implementation:
* change api to have caller allocated the qos request structures. (solve the kalloc issue)
* add plist use for constraint classes with hash-able dynamic ranges

Please have a look at the patch James posted earlier today on linux-pm, you were CCed.

Quoted 115 lines · mark gross

Quoted 87 lines · James Bottomley

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

Quoted 9 lines

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

True.

The following is what I think I'll work on this weekend. (hopefully have some sort of patch that at least compiles...)

Changes to pm_qos to enable "wakelock" or "suspend blocker" support:

Requirements:
1) atomic context support.
2) make updating request fast enough for hot path users.
3) Add a request class for "interactive_suspend", this particular request has a dynamic range of 1 (its 0 or 1). If zero then ok to auto suspend, if 1 then only user driven suspend. Whenever the aggregate request changes value the registered notifiers are called.

Quoted 4 lines

Implementation:
* change api to have caller allocated the qos request structures. (solve the kalloc issue)
* add plist use for constraint classes with hash-able dynamic ranges

Please have a look at the patch James posted earlier today on linux-pm, you were CCed.

Quoted 87 lines · James Bottomley

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

Quoted 9 lines

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

True.

The following is what I think I'll work on this weekend. (hopefully have some sort of patch that at least compiles...)

Changes to pm_qos to enable "wakelock" or "suspend blocker" support:

Requirements:
1) atomic context support.
2) make updating request fast enough for hot path users.
3) Add a request class for "interactive_suspend", this particular request has a dynamic range of 1 (its 0 or 1). If zero then ok to auto suspend, if 1 then only user driven suspend. Whenever the aggregate request changes value the registered notifiers are called.

Implementation:
* change api to have caller allocated the qos request structures. (solve the kalloc issue)
* add plist use for constraint classes with hash-able dynamic ranges

Quoted 64 lines · Arve Hjønnevåg

Quoted 63 lines · Rafael J. Wysocki

Quoted 61 lines · James Bottomley

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 5 lines

Quoted 2 lines

Agreed.

No, a hash is used for quick lookup of a specific value, not to find an extreme value.

If you only have N possible values an N bucket hash list is rather efficient (provided N is small). But I would agree that knowing what N is represents an API change, and since plists can do this without changing the API, they're better.

Quoted 2 lines

It is however extremely similar to plists. The only
difference is that plists link all the secondary lists together.

Right, so they would solve the *current* problem exactly.

Quoted 5 lines

If we
want to have constraints that autoexpire, then keeping the secondary lists separate allows the same optimization as I did for wakelock/suspend_blocker timeouts where no timer is active if an (equal or stricter) non-expiring constraint is active.

But this is a future discussion and not part of the patch. The way open source works is that we sort out the best implementation for the current conditions. If the implementation has to change because of future stuff, then we change it when the future stuff comes along. Changing implementations is easy (they don't have any externally visible impact). Changing the in-kernel API is slightly harder, but easily doable. It's only changing the user visible ABI that we worry about and try not to do.

Quoted 44 lines · Arve Hjønnevåg

Quoted 27 lines · mark gross

Quoted 26 lines · Brian Swetland

Quoted 24 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull. However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity. which would would well after I change the api to have the client allocate the memory for the nodes... BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

I think we will almost never see more than 10 list elements.

--mgross

Quoted 9 lines

Quoted 2 lines

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

shucks.

well I think for a pm_qos class that has boolean dynamic range we can get away with not walking the list on every request update. we can use a counter, and the list will be for mostly for stats.

Did you give any thought to my suggestion to only use one entry per unique value on the first level list and then use secondary lists of identical values. That way if you only have two constraints values the list you have to walk when updating a request will never have more than two entries regardless of how many total request you have.

Quoted 12 lines

A request update then becomes something like this:
if on primary list {
unlink from primary list
if secondary list is not empty
get next secondary entry and add in same spot on primary list
}
unlink from secondary list
find new spot on primary list
if already there
add to secondary list
else
add to primary list

This is just reinventing hash bucketed lists. To get the benefits, all we do is implement an N state constraint as backed by an N bucketed hash list, which the kernel already has all the internal mechanics for.

Quoted 19 lines · mark gross

Quoted 5 lines · Arve Hjønnevåg

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

what have you seen in practice from the wake-lock stats?

I'm having a hard time seeing where you could get more than just a handfull.  However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list, or we could simply remove them from the list uppon inactivity.  which would would well after I change the api to have the client allocate the memory for the nodes...  BUT, if your moving things in and out of a list a lot, I'm not sure the break even point where changing the structure helps.

We'll need to try it.

Quoted 5 lines

I think we will almost never see more than 10 list elements.

--mgross

I see about 80 (based on the batteryinfo dump) on my Nexus One (QSD8250, Android Froyo):

Kernel Wake lock "event5-86": (nothing executed)
Kernel Wake lock "PowerManagerService": 4m 27s 994ms (453 times) realtime Kernel Wake lock "event4-92": 72ms (10 times) realtime
Kernel Wake lock "AudioHardwareQSDIn": (nothing executed) Kernel Wake lock "event4-87": (nothing executed)
Kernel Wake lock "event5-82": (nothing executed)
Kernel Wake lock "event2-87": (nothing executed)
Kernel Wake lock "alarm_rtc": 21s 882ms (186 times) realtime Kernel Wake lock "vdec_suspend": (nothing executed)
Kernel Wake lock "event6-87": (nothing executed)
Kernel Wake lock "event0-91": (nothing executed)
Kernel Wake lock "SMD_DS": 30s 938ms (53 times) realtime Kernel Wake lock "event6-91": (nothing executed)
Kernel Wake lock "KeyEvents": 398ms (3226 times) realtime Kernel Wake lock "qmi1": (nothing executed)
Kernel Wake lock "mmc_delayed_work": (nothing executed)
Kernel Wake lock "event3-82": (nothing executed)
Kernel Wake lock "event3-92": 58ms (6 times) realtime
Kernel Wake lock "SMD_RPCCALL": 295ms (1756 times) realtime Kernel Wake lock "SMD_DATA6": (nothing executed)
Kernel Wake lock "audio_pcm_idle": 3s 99ms (1 times) realtime Kernel Wake lock "serial-debug": (nothing executed)
Kernel Wake lock "event6-82": (nothing executed)
Kernel Wake lock "event3-86": (nothing executed)
Kernel Wake lock "event2-82": (nothing executed)
Kernel Wake lock "i2c": (nothing executed)
Kernel Wake lock "event2-86": (nothing executed)
Kernel Wake lock "event5-87": (nothing executed)
Kernel Wake lock "event4-86": (nothing executed)
Kernel Wake lock "event5-92": 4ms (21 times) realtime
Kernel Wake lock "rpc_server": (nothing executed)
Kernel Wake lock "power-supply": 527ms (8 times) realtime Kernel Wake lock "radio-interface": 10s 11ms (10 times) realtime Kernel Wake lock "event6-86": (nothing executed)
Kernel Wake lock "deleted_wake_locks": 203ms (214 times) realtime Kernel Wake lock "qmi0": (nothing executed)
Kernel Wake lock "event2-91": (nothing executed)
Kernel Wake lock "event4-82": (nothing executed)
Kernel Wake lock "event7-82": (nothing executed)
Kernel Wake lock "dock": 27ms (1 times) realtime
Kernel Wake lock "SMD_DATA5": 1m 45s 121ms (158 times) realtime Kernel Wake lock "event1-92": (nothing executed)
Kernel Wake lock "gpio_kp": (nothing executed)
Kernel Wake lock "event3-87": (nothing executed)
Kernel Wake lock "event7-92": (nothing executed)
Kernel Wake lock "msm_serial_hs_dma": (nothing executed) Kernel Wake lock "event5-91": (nothing executed)
Kernel Wake lock "vbus_present": 517ms (1 times) realtime Kernel Wake lock "alarm": 3s 229ms (249 times) realtime Kernel Wake lock "event1-82": (nothing executed)
Kernel Wake lock "venc_suspend": (nothing executed)
Kernel Wake lock "event1-86": (nothing executed)
Kernel Wake lock "AudioHardwareQSDOut": 3s 98ms (1 times) realtime Kernel Wake lock "event0-87": (nothing executed)
Kernel Wake lock "event2-92": 169ms (687 times) realtime Kernel Wake lock "ds2784-battery": 12s 846ms (158 times) realtime Kernel Wake lock "ApmCommandThread": 564ms (2 times) realtime Kernel Wake lock "msmfb_idle_lock": 1s 495ms (715 times) realtime Kernel Wake lock "headset": (nothing executed)
Kernel Wake lock "kgsl": 26s 473ms (123 times) realtime Kernel Wake lock "venc_idle": (nothing executed)
Kernel Wake lock "event1-91": (nothing executed)
Kernel Wake lock "s5k3e2fx": (nothing executed)
Kernel Wake lock "usb_mass_storage": (nothing executed)
Kernel Wake lock "unknown_wakeups": (nothing executed)
Kernel Wake lock "vdec_idle": (nothing executed)
Kernel Wake lock "audio_pcm_suspend": 3s 99ms (1 times) realtime Kernel Wake lock "microp_i2c_present": (nothing executed) Kernel Wake lock "event4-91": (nothing executed)
Kernel Wake lock "event6-92": 182ms (86 times) realtime Kernel Wake lock "event0-82": (nothing executed)
Kernel Wake lock "event0-92": 8ms (37 times) realtime
Kernel Wake lock "rpc_read": 112ms (1540 times) realtime Kernel Wake lock "event0-86": (nothing executed)
Kernel Wake lock "msm_serial_hs_rx": (nothing executed)

Kernel Wake lock "qmi2": (nothing executed) Kernel Wake lock "event1-87": (nothing executed) Kernel Wake lock "msm_camera": (nothing executed) Kernel Wake lock "rpc-interface": 2ms (1 times) realtime Kernel Wake lock "main": 1m 38s 314ms (5 times) realtime Kernel Wake lock "gpio_input": (nothing executed) Kernel Wake lock "event3-91": (nothing executed) Kernel Wake lock "SMD_DATA7": (nothing executed)

However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list,

However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list,

Quoted 2 lines · mark gross

However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list,

/me suggests you take a new look at the scheduler, those lists disappeared more than 10 releases ago. We use RB-trees these days.

Quoted 2 lines · mark gross

However; one could go to a dual list (like the scheduler) and move inactive nodes from an active to inactive list,

/me suggests you take a new look at the scheduler, those lists disappeared more than 10 releases ago. We use RB-trees these days.

2010/6/2 mark gross <[email protected]>:

Quoted 27 lines · Arve Hjønnevåg

Quoted 19 lines · mark gross

Quoted 1 line · Florian Mickler

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);

kernel/pm_qos_params.c +2 -0

+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced.  But, this idea is a good improvement i'll roll into the next pm_qos update!

Quoted 6 lines

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 6 lines

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel.  Wherever the list tended to be short, a simple list wins.  However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

The list is not short. You have all the inactive and active constraints on the same list. If you change it to a two level list though, the list of unique values (which is the list you have to walk) may be short enough for a tree to be overkill.

Quoted 19 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

Quoted 6 lines

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

Quoted 27 lines · mark gross

Quoted 25 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 5 lines

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

How many different values are there to handle?

Quoted 28 lines · Rafael J. Wysocki

Quoted 27 lines · mark gross

Quoted 25 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 8 lines

Quoted 5 lines

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

How many different values are there to handle?

for the current pm_qos users its tiny. I've never heard of more than a few < 10. However; for the new "interactive" class to provide suspend blocker functionality, I expect the number to be up to 20.

but realistically I bet we never get more than 10ish.

One constraint constraint request per module from isr to user mode. Once in user mode there would be only a few (assuming Android user space) I think just from the power HAL, input HAL, and the RIL.

Still a pretty small number I don't think we need to worry about scaling as much as we need to worry about performance.

Quoted 28 lines · Rafael J. Wysocki

Quoted 27 lines · mark gross

Quoted 25 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 8 lines

Quoted 5 lines

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

How many different values are there to handle?

for the current pm_qos users its tiny. I've never heard of more than a few < 10. However; for the new "interactive" class to provide suspend blocker functionality, I expect the number to be up to 20.

but realistically I bet we never get more than 10ish.

One constraint constraint request per module from isr to user mode. Once in user mode there would be only a few (assuming Android user space) I think just from the power HAL, input HAL, and the RIL.

Still a pretty small number I don't think we need to worry about scaling as much as we need to worry about performance.

Quoted 27 lines · mark gross

Quoted 25 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 5 lines

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

How many different values are there to handle?

Quoted 19 lines · Arve Hjønnevåg

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

kernel/pm_qos_params.c +4 -0

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);
+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced. But, this idea is a good improvement i'll roll into the next pm_qos update!

Quoted 6 lines

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

I don't agree, we went through this tree vrs list discussion a few times before in other areas of the kernel. Wherever the list tended to be short, a simple list wins. However; we can try it, after we have some metrics and stress test cases identified we can measure its effectivenes against.

Quoted 1 line · mark gross

On Tue, Jun 01, 2010 at 09:07:37AM +0200, Florian Mickler wrote:

...

Quoted 6 lines

Quoted 6 lines

kernel/pm_qos_params.c +6 -0

+static void update_target_val(int pm_qos_class, s32 val)
+{
+     s32 extreme_value;
+     s32 new_value;
+     extreme_value = atomic_read(&pm_qos_array[pm_qos_class]->target_value);
+     new_value = pm_qos_array[pm_qos_class]->comparitor(val,extreme_value);

Quoted 9 lines

kernel/pm_qos_params.c static s32 min_compare(s32 v1, s32 v2) · line 148

Quoted 4 lines

+     if (extreme_value != new_value)
+             atomic_set(&pm_qos_array[pm_qos_class]->target_value,new_value);

kernel/pm_qos_params.c +2 -0

+}
+

Only works 1/2 the time, but I like the idea!
It fails to get the righ answer when constraints are reduced.  But, this idea is a good improvement i'll roll into the next pm_qos update!

I think it would be a better idea to track your constraints with a sorted data structure. That way you can to better than O(n) for both directions. If you have a lot of constraints with the same value, it may even be worthwhile to have a two stage structure where for instance you use a rbtree for the unique values and list for identical constraints.

Quoted 26 lines · On Mon, 31 May 2010 16:26:17 -0700 mark gross <[email protected]> wrote:

Quoted 18 lines · Rafael J. Wysocki

Quoted 17 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 15 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

Quoted 6 lines

Quoted 2 lines

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

Quoted 7 lines

I'm pretty sure it can be called in atomic context, and if its not I'm sure we can fix that. It can be called in atomic context. I don't think it was ever a problem to call it in atomic context. The problem it had was that crappy list of string compares. Thats been fixed.

--mgross

Well, the register call uses kzalloc. Apart from that I think we're good.

The outstanding list traversals can be fixed also. (see below)

Cheers,
Flo

From 66fdd76f8cc4be722dba3859ddadfe07e7a4b755 Mon Sep 17 00:00:00 2001
From: Florian Mickler <[email protected]>
Date: Tue, 1 Jun 2010 09:04:26 +0200
Subject: [PATCH] pm_qos: remove unnecessary list-traversal

The new extreme_value is only depending on the old extreme_value and the changing value.

Signed-off-by Florian Mickler <[email protected]>

---
 kernel/pm_qos_params.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

kernel/pm_qos_params.c +0 -0

index f42d3f7..6618e2c 100644
@@ -136,6 +136,16 @@ static s32 min_compare(s32 v1, s32 v2)
 }
 
 

kernel/pm_qos_params.c +4 -6

 static void update_target(int pm_qos_class)
 {
 	s32 extreme_value;

@@ -227,8 +237,8 @@ struct pm_qos_request_list *pm_qos_add_request(int pm_qos_class, s32 value)
 		spin_lock_irqsave(&pm_qos_lock, flags);
 		list_add(&dep->list,
 			&pm_qos_array[pm_qos_class]->requests.list);
+		update_target_val(pm_qos_class,dep->value);
 		spin_unlock_irqrestore(&pm_qos_lock, flags);
-		update_target(pm_qos_class);
 	}
 
 	return dep;

@@ -249,23 +259,21 @@ void pm_qos_update_request(struct pm_qos_request_list *pm_qos_req,
 		s32 new_value)
 {
 	unsigned long flags;
-	int pending_update = 0;
 	s32 temp;
 
 	if (pm_qos_req) { /*guard against callers passing in null */
+		int target = pm_qos_req->pm_qos_class;
 		spin_lock_irqsave(&pm_qos_lock, flags);
 		if (new_value == PM_QOS_DEFAULT_VALUE)
-			temp = pm_qos_array[pm_qos_req->pm_qos_class]->default_value;
+			temp = pm_qos_array[target]->default_value;
 		else
 			temp = new_value;
 
 		if (temp != pm_qos_req->value) {
-			pending_update = 1;
 			pm_qos_req->value = temp;
+			update_target_val(target,temp);
 		}
 		spin_unlock_irqrestore(&pm_qos_lock, flags);
-		if (pending_update)
-			update_target(pm_qos_req->pm_qos_class);
 	}
 }
 EXPORT_SYMBOL_GPL(pm_qos_update_request);

Signature · 1 line

1.7.1

Quoted 31 lines · On Mon, 31 May 2010 16:26:17 -0700 mark gross <[email protected]> wrote:

Quoted 18 lines · Rafael J. Wysocki

Quoted 17 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 15 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

Quoted 6 lines

Quoted 2 lines

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

I'm pretty sure it can be called in atomic context, and if its not I'm sure we can fix that. It can be called in atomic context. I don't think it was ever a problem to call it in atomic context. The problem it had was that crappy list of string compares. Thats been fixed.

Quoted 2 lines

--mgross

Well, the register call uses kzalloc. Apart from that I think we're good.

Quoted 31 lines · On Mon, 31 May 2010 16:26:17 -0700 mark gross <[email protected]> wrote:

Quoted 18 lines · Rafael J. Wysocki

Quoted 17 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 15 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

Quoted 6 lines

Quoted 2 lines

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

I'm pretty sure it can be called in atomic context, and if its not I'm sure we can fix that. It can be called in atomic context. I don't think it was ever a problem to call it in atomic context. The problem it had was that crappy list of string compares. Thats been fixed.

Quoted 2 lines

--mgross

Well, the register call uses kzalloc. Apart from that I think we're good.

Quoted 21 lines · Rafael J. Wysocki

Quoted 19 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 7 lines · Arve Hjønnevåg

Quoted 6 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

Quoted 8 lines

Quoted 3 lines

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

Quoted 3 lines

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

I'm pretty sure it can be called in atomic context, and if its not I'm sure we can fix that. It can be called in atomic context. I don't think it was ever a problem to call it in atomic context. The problem it had was that crappy list of string compares. Thats been fixed.

--mgross

Quoted 19 lines

Quoted 2 lines

Also, it does not have any state constraints, so it iterates over every registered constraint each time one of them changes.

That's fixable IMO.

Quoted 1 line

Nor does is currently provide any stats for debugging.

That's why Alan is proposing to add that.

Quoted 4 lines

The original wakelock patchset supported a wakelock type so it could be used to block more then suspend, but I had to remove this because it "overlapped" with pm-qos. So, yes I do consider this just another rename.

It's an extension of an existing framework rather than an addition of a new one, with entirely new API and so on. Extending existing APIs is much preferred to adding new ones, in general.

Rafael

Quoted 21 lines · Rafael J. Wysocki

Quoted 19 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 7 lines · Arve Hjønnevåg

Quoted 6 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

Quoted 8 lines

Quoted 3 lines

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

Quoted 3 lines

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

I'm pretty sure it can be called in atomic context, and if its not I'm sure we can fix that. It can be called in atomic context. I don't think it was ever a problem to call it in atomic context. The problem it had was that crappy list of string compares. Thats been fixed.

--mgross

Quoted 19 lines

Quoted 2 lines

Also, it does not have any state constraints, so it iterates over every registered constraint each time one of them changes.

That's fixable IMO.

Quoted 1 line

Nor does is currently provide any stats for debugging.

That's why Alan is proposing to add that.

Quoted 4 lines

The original wakelock patchset supported a wakelock type so it could be used to block more then suspend, but I had to remove this because it "overlapped" with pm-qos. So, yes I do consider this just another rename.

It's an extension of an existing framework rather than an addition of a new one, with entirely new API and so on. Extending existing APIs is much preferred to adding new ones, in general.

Rafael

Quoted 17 lines · Arve Hjønnevåg

2010/5/29 Alan Stern <[email protected]>:

Quoted 15 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

Quoted 2 lines

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

We've just merged a patch that fixed that if I'm not mistaken. Mark, did your PM QoS update fix that?

Quoted 2 lines

Also, it does not have any state constraints, so it iterates over every registered constraint each time one of them changes.

That's fixable IMO.

Quoted 1 line

Nor does is currently provide any stats for debugging.

That's why Alan is proposing to add that.

Quoted 4 lines

The original wakelock patchset supported a wakelock type so it could be used to block more then suspend, but I had to remove this because it "overlapped" with pm-qos. So, yes I do consider this just another rename.

It's an extension of an existing framework rather than an addition of a new one, with entirely new API and so on. Extending existing APIs is much preferred to adding new ones, in general.

Rafael

2010/5/29 Alan Stern <[email protected]>:

Quoted 11 lines · Arve Hjønnevåg

Quoted 9 lines

Quoted 6 lines

In place of in-kernel suspend blockers, there will be a new type of QoS constraint -- call it QOS_EVENTUALLY. It's a very weak constraint, compatible with all cpuidle modes in which runnable threads are allowed to run (which is all of them), but not compatible with suspend.

This sound just like another API rename. It will work, but given that suspend blockers was the name least objectionable last time around, I'm not sure what this would solve.

Quoted 4 lines

It's not just a rename. By changing this into a QoS constraint, we make it more generally useful. Instead of standing on its own, it becomes part of the PM-QOS framework.

We cannot use the existing pm-qos framework. It is not safe to call from atomic context.

Also, it does not have any state constraints, so it iterates over every registered constraint each time one of them changes.

Nor does is currently provide any stats for debugging.

The original wakelock patchset supported a wakelock type so it could be used to block more then suspend, but I had to remove this because it "overlapped" with pm-qos. So, yes I do consider this just another rename.

Quoted 7 lines · Florian Mickler

Quoted 3 lines · On Sat, 29 May 2010 00:11:32 +0200 "Rafael J. Wysocki" <[email protected]> wrote:

Having reconsidered the suspend blockers idea I came to the conclusion that in fact it was a workaround for three different problems.

Quoted 5 lines

But it is also a change of paradigm. The scheduler should strive to have the system idle as long as possible to conserve battery. And everything that does not serve the purpose of the device has to be considered as not worth running, except if there are other purpose-fullfilling tasks to run anyway.

No the purpose of the scheduler is to run tasks when they are runnable. Not to second guess whatever caused them to become runnable.

If you start to randomly not run tasks, the inversion chaos that ensues is terrible.

You can apply the regular means of alleviating that and
that entails adding *-inheritance to all blockable resources. The -rt patch set is doing that in part.

You really need to make applications not want to run and block on their own volition (in a resource free point) and otherwise make them block on something forcefully and disregard any malfunctioning that would result from that, and in extreme cases terminate (releasing all resources).

But really Android shouldn't even need kernel support to do all this, since its hosted on this massive middle-ware that intercepts everything, called a Java Virtual Machine.

Now, all I'm interested in is providing interfaces from the kernel where needed, so that userspace can be optimally frugal with power usage, and can monitor/contain badly behaving tasks.

If Android is so set in its ways that they don't want to adopt (like saying Android requires suspend for power management) then they can go their own merry way and I'm not interested anymore (it would be a shame though).

Quoted 7 lines · Florian Mickler

Quoted 3 lines · On Sat, 29 May 2010 00:11:32 +0200 "Rafael J. Wysocki" <[email protected]> wrote:

Having reconsidered the suspend blockers idea I came to the conclusion that in fact it was a workaround for three different problems.

Quoted 5 lines

But it is also a change of paradigm. The scheduler should strive to have the system idle as long as possible to conserve battery. And everything that does not serve the purpose of the device has to be considered as not worth running, except if there are other purpose-fullfilling tasks to run anyway.

No the purpose of the scheduler is to run tasks when they are runnable. Not to second guess whatever caused them to become runnable.

If you start to randomly not run tasks, the inversion chaos that ensues is terrible.

You can apply the regular means of alleviating that and
that entails adding *-inheritance to all blockable resources. The -rt patch set is doing that in part.

You really need to make applications not want to run and block on their own volition (in a resource free point) and otherwise make them block on something forcefully and disregard any malfunctioning that would result from that, and in extreme cases terminate (releasing all resources).

But really Android shouldn't even need kernel support to do all this, since its hosted on this massive middle-ware that intercepts everything, called a Java Virtual Machine.

Now, all I'm interested in is providing interfaces from the kernel where needed, so that userspace can be optimally frugal with power usage, and can monitor/contain badly behaving tasks.

If Android is so set in its ways that they don't want to adopt (like saying Android requires suspend for power management) then they can go their own merry way and I'm not interested anymore (it would be a shame though).

Quoted 7 lines · Arve Hjønnevåg

What happens if the user presses the button right before you set QoS of 'user apps' to QS_NONE?
To me it looks like this solution would result in this sequence which may ignore the button press:
Button pushed
Button driver sets QoS of app it wakes to QS_ABOVESUSPEND Set QoS of 'user apps' to QS_NONE

I don't think we should change app QoS parameters, but change service provider parameters.

For instance, suppose the filesystem-IO QoS has 3 levels:
High, Normal and Idle.

Then if we assign Idle to updatedb, we'll service it as long as the filesystem-server QoS has a higher level (High and Normal). When we change the filesystem-serves' QoS to idle, it finds there is nothing to keep it servicing stuff and it'll block pending requests, updatedb stops being runnable and we're good.

What happens if the user presses the button right before you set QoS of 'user apps' to QS_NONE?
To me it looks like this solution would result in this sequence which may ignore the button press:
Button pushed
Button driver sets QoS of app it wakes to QS_ABOVESUSPEND Set QoS of 'user apps' to QS_NONE

This is a much harder question to answer that what we need to use opportunistic suspend. The question we ask is more like this: "Is all important work complete?". In the simplest case these can be the same,

What happens if the user presses the button right before you set QoS of 'user apps' to QS_NONE?

To me it looks like this solution would result in this sequence which may ignore the button press:
       Button pushed
       Button driver sets QoS of app it wakes to QS_ABOVESUSPEND Set QoS of 'user apps' to QS_NONE

Quoted 7 lines

       That would I think solve the reliable wakeup case although drivers raising a QoS parameter is a bit unusual in the kernel. That would at least however be specific to a few Android drivers and maybe a tiny amount of shared driver stuff so probably not unacceptable. (wake_up_pri(&queue, priority); isn't going to kill anyone is it - especially if it usually ignores the priority argument)

Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

What happens if the button press happend before this line:

Quoted 10 lines

       count2 = tasks to QS_NONE | QS_NOTCHANGED Screen off
                                       Button Press task to QS_ABOVESUSPEND count = tasks that are QS_NOTCHANGED to QS_NONE

       if (count != count2) {
               Stuff happened ... rethink
       }

Quoted 5 lines

That is still a bit weird and wonderful but all the logic is in the right places. The special magic remains in the Android policy code and in the kernel specifics for Android.

Thoughts ?

I don't think it works. Also, it does not seem much less invasive than suspend blockers.

Quoted 3 lines

This is a much harder question to answer that what we need to use opportunistic suspend. The question we ask is more like this: "Is all important work complete?". In the simplest case these can be the same,

I don't believe you can answer that question without telepathy and a crystal ball.

The application doesn't know because it has no idea how to balance conflicting resource demands or to infer the users requirements and wishes. Most apps will misbehave anyway.

The OS doesn't know because it cannot tell what the app wants

So at best you have a heuristic.

Quoted 2 lines

What happens if the user presses the button right before you set QoS of 'user apps' to  QS_NONE?

Read down a paragraph.

Quoted 15 lines

To me it looks like this solution would result in this sequence which may ignore the button press:
        Button pushed
        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND Set QoS of 'user apps' to QS_NONE

Quoted 7 lines

       That would I think solve the reliable wakeup case although drivers raising a QoS parameter is a bit unusual in the kernel. That would at least however be specific to a few Android drivers and maybe a tiny amount of shared driver stuff so probably not unacceptable. (wake_up_pri(&queue, priority); isn't going to kill anyone is it - especially if it usually ignores the priority argument)

Quoted 1 line

Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

We keep it kernel side
It expresses policy and wishes rather than enforcing a behaviour.

What for example does "suspend_block" mean on a virtual machine ?

I would prefer "priority" was some kind of resource constraint model instead but I'm just trying to think how to be absolutely minimally invasible at this point.

Quoted 15 lines

What happens if the button press happend before this line:

Quoted 14 lines

       count2 = tasks to QS_NONE | QS_NOTCHANGED Screen off
                                       Button Press task to QS_ABOVESUSPEND count = tasks that are QS_NOTCHANGED to QS_NONE

       if (count != count2) {
               Stuff happened ... rethink
       }

That is still a bit weird and wonderful but all the logic is in the right places. The special magic remains in the Android policy code and in the kernel specifics for Android.

Quoted 4 lines

Quoted 1 line

Thoughts ?

I don't think it works. Also, it does not seem much less invasive than suspend blockers.

"I don't think it works" isn't that helpful. I don't think it works because .. would help me a lot more.

Quoted 2 lines

What happens if the button press happend before this line:

Quoted 1 line

       count2 = tasks to QS_NONE | QS_NOTCHANGED

Quoted 3 lines

This is a much harder question to answer that what we need to use opportunistic suspend. The question we ask is more like this: "Is all important work complete?". In the simplest case these can be the same,

I don't believe you can answer that question without telepathy and a crystal ball.

The application doesn't know because it has no idea how to balance conflicting resource demands or to infer the users requirements and wishes. Most apps will misbehave anyway.

The OS doesn't know because it cannot tell what the app wants

So at best you have a heuristic.

Quoted 2 lines

What happens if the user presses the button right before you set QoS of 'user apps' to  QS_NONE?

Read down a paragraph.

Quoted 15 lines

To me it looks like this solution would result in this sequence which may ignore the button press:
        Button pushed
        Button driver sets QoS of app it wakes to QS_ABOVESUSPEND Set QoS of 'user apps' to QS_NONE

Quoted 7 lines

       That would I think solve the reliable wakeup case although drivers raising a QoS parameter is a bit unusual in the kernel. That would at least however be specific to a few Android drivers and maybe a tiny amount of shared driver stuff so probably not unacceptable. (wake_up_pri(&queue, priority); isn't going to kill anyone is it - especially if it usually ignores the priority argument)

Quoted 1 line

Why is "wake_up_pri(&queue, priority)" more acceptable than "suspend_block(..."?

We keep it kernel side
It expresses policy and wishes rather than enforcing a behaviour.

What for example does "suspend_block" mean on a virtual machine ?

I would prefer "priority" was some kind of resource constraint model instead but I'm just trying to think how to be absolutely minimally invasible at this point.

Quoted 15 lines

What happens if the button press happend before this line:

Quoted 14 lines

       count2 = tasks to QS_NONE | QS_NOTCHANGED Screen off
                                       Button Press task to QS_ABOVESUSPEND count = tasks that are QS_NOTCHANGED to QS_NONE

       if (count != count2) {
               Stuff happened ... rethink
       }

That is still a bit weird and wonderful but all the logic is in the right places. The special magic remains in the Android policy code and in the kernel specifics for Android.

Quoted 4 lines

Quoted 1 line

Thoughts ?

I don't think it works. Also, it does not seem much less invasive than suspend blockers.

"I don't think it works" isn't that helpful. I don't think it works because .. would help me a lot more.

Quoted 2 lines

What happens if the button press happend before this line:

Quoted 1 line

       count2 = tasks to QS_NONE | QS_NOTCHANGED

Quoted 9 lines

That's correct, but to me the Arve's goal is simply to maximize battery life and he found experimentally that the longest battery life is achieved if system suspend is used whenever the system doesn't need to be active (from its user's perspective).  This actually is different from "when the system is idle", because the system isn't idle, for example, when updatedb is running. However, from the user's perspective the updatedb process doesn't really need to run at this particular time, it can very well do it's job in parallel with the user typing or reading news.  So, the system may very well be suspended when updatedb is running.

This is where the original questions around QoS came in

Quoted 4 lines

Since I think we've now rejected the feature, do we have a clear picture about what the Android people should do _instead_ and yet keep the battery life they want?  Because I don't think telling "let them do what they want, who cares" is right.

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

- How do we define who matters: QoS ?

- Can you describe "idle" in terms of QoS without then breaking the reliable wakeup for an event (and do you need to ?)

       Could this for example look like

       Set QoS of 'user apps' to QS_NONE
       Button pushed
       Button driver sets QoS of app it wakes to QS_ABOVESUSPEND

       That would I think solve the reliable wakeup case although drivers raising a QoS parameter is a bit unusual in the kernel. That would at least however be specific to a few Android drivers and maybe a tiny amount of shared driver stuff so probably not unacceptable. (wake_up_pri(&queue, priority); isn't going to kill anyone is it - especially if it usually ignores the priority argument)

       I am curious Thomas how that would tie in with PI in the RT world, it's effectively inheriting priority from the users finger.

- Would a model where the UI side behaviour looked like

       Timeout
       Screen Off
       Set QoS of 'user apps' to QS_NONE

       Event
       [Some chain of activity]
       Screen On
       Set QoS of 'user apps' to QS_ABOVESUSPEND

 do the job combined with the ability to see who is stopping us dropping to suspend so user space can take action. This could be a data table from the Android cpu manager provided to Android specific policy in whoever owns the display.

If so how do we fix the UI policy code doing

       Screen Off
                                       Button Press task to QS_ABOVESUSPEND task to QS_NONE

without touching the app userspace code

Perhaps

       count2 = tasks to QS_NONE | QS_NOTCHANGED Screen off
                                       Button Press task to QS_ABOVESUSPEND count = tasks that are QS_NOTCHANGED to QS_NONE

       if (count != count2) {
               Stuff happened ... rethink
       }

That is still a bit weird and wonderful but all the logic is in the right places. The special magic remains in the Android policy code and in the kernel specifics for Android.

Thoughts ?

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

Quoted 4 lines · Alan Cox

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

I'm not sure we need or want to go there.

Why not simply let upatedb block on its IO because its QoS policy tells us that its IO priority is idle. Therefore it will not avoid the IO device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

Quoted 8 lines · Peter Zijlstra

Quoted 4 lines · Alan Cox

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

I'm not sure we need or want to go there.

Quoted 7 lines

Why not simply let upatedb block on its IO because its QoS policy tells us that its IO priority is idle. Therefore it will not avoid the IO device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

There may be apps that don't actually do I/O that we may want to be treated that way too.

Consider the following scenario. I have a purely computational task that's running on my laptop in the background (say it's a folding@home or something similar), but I only want it to run when (a) the box is on AC power and (b) when user interface is "active" (the latter would have to be defined precisely, but for the purpose of this thought experiment let's assume we have such a definition). Then, I'd only like it to be regarded as runnable if (a) and (b) both happen at the same time, but it can't block on I/O.

Quoted 8 lines · Peter Zijlstra

Quoted 4 lines · Alan Cox

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

I'm not sure we need or want to go there.

Quoted 7 lines

Why not simply let upatedb block on its IO because its QoS policy tells us that its IO priority is idle. Therefore it will not avoid the IO device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

There may be apps that don't actually do I/O that we may want to be treated that way too.

Consider the following scenario. I have a purely computational task that's running on my laptop in the background (say it's a folding@home or something similar), but I only want it to run when (a) the box is on AC power and (b) when user interface is "active" (the latter would have to be defined precisely, but for the purpose of this thought experiment let's assume we have such a definition). Then, I'd only like it to be regarded as runnable if (a) and (b) both happen at the same time, but it can't block on I/O.

Quoted 4 lines · Alan Cox

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

I'm not sure we need or want to go there.

Why not simply let upatedb block on its IO because its QoS policy tells us that its IO priority is idle. Therefore it will not avoid the IO device from going idle and indefinitely delaying servicing requests.

When updatedb blocks, the runqueue becomes empty and we gain goodness.

Or are we talking about the same thing?

Today "idle" means "no task running"

If you are prepared to rephrase that as "no task that matters is running" what would need to answer ?

That's correct, but to me the Arve's goal is simply to maximize battery life and he found experimentally that the longest battery life is achieved if system suspend is used whenever the system doesn't need to be active (from its user's perspective). This actually is different from "when the system is idle", because the system isn't idle, for example, when updatedb is running. However, from the user's perspective the updatedb process doesn't really need to run at this particular time, it can very well do it's job in parallel with the user typing or reading news. So, the system may very well be suspended when updatedb is running.

Since I think we've now rejected the feature, do we have a clear picture about what the Android people should do _instead_ and yet keep the battery life they want? Because I don't think telling "let them do what they want, who cares" is right.

No, it's not. Forced suspend may be in response to hitting a key, but it

may also be in response to a 30 minute timeout expiring. If I get a WoL packet in the 0.5 of a second between userspace deciding to suspend and actually doing so, the system shouldn't suspend.

Quoted 2 lines · Peter Zijlstra

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers. That's entirely orthogonal to Android's runtime power management.

Quoted 2 lines · Peter Zijlstra

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers.

Quoted 2 lines · Peter Zijlstra

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers.

Quoted 2 lines · Peter Zijlstra

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers. That's entirely orthogonal to Android's runtime power management.

Quoted 2 lines · Peter Zijlstra

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

If you want to support forced suspend for laptops and you want to avoid the risk of losing wakeups then you need in-kernel suspend blockers. That's entirely orthogonal to Android's runtime power management.

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

Quoted 2 lines

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

I don't think this is true. I think that is the root of the problem.

I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend.

So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Quoted 2 lines

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

I don't think this is true. I think that is the root of the problem.

I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend.

So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Quoted 4 lines · Alan Cox

Quoted 2 lines

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

I don't think this is true. I think that is the root of the problem.

Of course it's true. Just ask Arve -- he wants opportunistic suspend and it _is_ a variant of forced suspend. Ergo he wants a new type of forced suspend.

Maybe that's not what he _ought_ to want. Nevertheless, there are valid reasons for wanting it.

Quoted 9 lines

I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend.

Quoted 6 lines

So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Currently we use the freezer. But it is a blunt tool -- it freezes every user process. Also, it doesn't actually make processes unrunnable; it just arranges things so that when they do run, they immediately put themselves back to sleep.

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

Quoted 4 lines

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)?

Quoted 11 lines · Rafael J. Wysocki

Quoted 4 lines

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)?

We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver.

Quoted 11 lines · Rafael J. Wysocki

Quoted 4 lines

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)?

We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver.

Quoted 14 lines · Alan Stern

Quoted 11 lines · Rafael J. Wysocki

Quoted 4 lines

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)?

Quoted 2 lines

We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver.

But what if its the _right_ thing to do? We make changes to every device driver out there on a regular basis. Also, why won't an incremental process work? Add the interface with a fallback for drivers that haven't implemented it and implement it for those drivers its most urgent (like those in use on an Android phone).

Not doing the right thing simply because its a lot of work seems like a fine way to let the kernel rot into an unmaintainable mess.

Quoted 14 lines · Alan Stern

Quoted 11 lines · Rafael J. Wysocki

Quoted 4 lines

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

We could avoid that if drivers could block tasks, but there are questions to answer. First off, how a driver is supposed to know when to block the task using it and when to do its power management transparently for the task? Second, how to intercept and block all possible interfaces that user space can use to talk to drivers (how to intercept a task using mmapped device, for example)?

Quoted 2 lines

We talked about this a few years ago and decided it was not feasible. It would require substantial changes to every device driver.

But what if its the _right_ thing to do? We make changes to every device driver out there on a regular basis. Also, why won't an incremental process work? Add the interface with a fallback for drivers that haven't implemented it and implement it for those drivers its most urgent (like those in use on an Android phone).

Not doing the right thing simply because its a lot of work seems like a fine way to let the kernel rot into an unmaintainable mess.

Quoted 4 lines · Alan Cox

Quoted 2 lines

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

I don't think this is true. I think that is the root of the problem.

Of course it's true. Just ask Arve -- he wants opportunistic suspend and it _is_ a variant of forced suspend. Ergo he wants a new type of forced suspend.

Maybe that's not what he _ought_ to want. Nevertheless, there are valid reasons for wanting it.

Quoted 9 lines

I don't disagree with the user experience they are trying to create or the fact something is needed to make it possible (if it turns out we can't already do it).

Forced suspend is sticking stuff in running state into suspend

Power management models (such as Thomas ARM box) which we know work are 'when nothing is running' into suspend.

Quoted 6 lines

So for me the real question on that side of this specific case is 'how do you make sure those tasks are idle when you need them to be'

QoS ?
Spanking them from user space ?
Drivers enforcing policy elements by blocking tasks ?

Currently we use the freezer. But it is a blunt tool -- it freezes every user process. Also, it doesn't actually make processes unrunnable; it just arranges things so that when they do run, they immediately put themselves back to sleep.

And the forced-suspend design relies on the fact that processes remain frozen throughout. If we leave some processes unfrozen and one of them somehow becomes runnable, that means we have to abort the forced suspend before the process is allowed to run.

Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a

Shall we henceforth stop confusing forced suspend for laptops and powersaving a running system?

Quoted 1 line · Matthew Garrett

Even if we could use suspend-via-deep-idle-state on PCs,

( see Alan Cox's argument on PCs )

Quoted 1 line

we still need to be able to enter suspend while the system isn't idle.

_WHY_!?

We've been trying to tell you you don't need that.

Even if we could use suspend-via-deep-idle-state on PCs,

we still need to be able to enter suspend while the system isn't idle.

Quoted 4 lines · Thomas Gleixner

Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that:

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

Quoted 11 lines · Matthew Garrett

Quoted 4 lines · Thomas Gleixner

Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that:

Quoted 7 lines

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed.

The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise.

Thanks,

tglx

Quoted 11 lines · Matthew Garrett

Quoted 4 lines · Thomas Gleixner

Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that:

Quoted 7 lines

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed.

The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise.

Thanks,

tglx

Quoted 38 lines · On Thu, 27 May 2010 20:05:39 +0200 (CEST) Thomas Gleixner <[email protected]>…

Quoted 11 lines · Matthew Garrett

Quoted 4 lines · Thomas Gleixner

Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that:

Quoted 7 lines

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed.

Quoted 6 lines

The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise.

Thanks,

      tglx

Thomas,
do you really have a problem with the actual concept? Or do you just don't like the way it is done?

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

Quoted 38 lines · On Thu, 27 May 2010 20:05:39 +0200 (CEST) Thomas Gleixner <[email protected]>…

Quoted 11 lines · Matthew Garrett

Quoted 4 lines · Thomas Gleixner

Oh no. They paper over a short coming. If there is a pending event, the kernel knows that. It just does not make use of this information. Blockers just paper over this by sprinkling do_not_suspend() calls all over the place. What a sensible solution.

Even if we could use suspend-via-deep-idle-state on PCs, we still need to be able to enter suspend while the system isn't idle. There's two ways to do that:

Quoted 7 lines

1) Force the system to be idle. Doing this race-free is difficult.

2) Enter suspend even though the system isn't idle. Since we can't rely on the scheduler, we need drivers to know whether userspace has consumed all wakeup events before allowing the transition to occur. Doing so requires either in-kernel suspend blockers or something that's almost identical.

You're just not getting it. If user space has consumed the event is not relevant at all.

What's relevant is whether the app has processed the event and reacted accordingly. That's all that matters.

Emptying your input queue is just the wrong indicator.

And as I explained several times now: It does _NOT_ matter when the app goes back in to blocked/idle state. You have to spend the CPU cycles and power for that anyway.

And for the apps which do not use the user space blockers the queue empty indicator is just bullshit, because after emptying the queue the kernel can go into suspend w/o any guarantee that the event has been processed.

Quoted 6 lines

The whole concept sucks, as it does not solve anything. Burning power now or in 100ms is the same thing power consumption wise.

Thanks,

      tglx

Thomas,
do you really have a problem with the actual concept? Or do you just don't like the way it is done?

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

Quoted 4 lines

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the device.

Quoted 9 lines

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

OK.

Quoted 4 lines

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be annotated.

Quoted 7 lines

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

If nothing blocks suspend. The reason to block suspend does not have to be direct user interaction.

Quoted 4 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 19 lines

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Quoted 5 lines

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

I'm not sure what you mean.

Quoted 5 lines · On Fri, 28 May 2010 02:18:06 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 4 lines

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

Quoted 12 lines

That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the device.

Damn. I just want to put some abstract notion around this approach to power saving.

But one could say instead of "direct" interaction, that every time a suspend blocker is taken it is "on behalf of the user"?

So if a suspend blocker is taken, because a download is in progress, it is on behalf of (direct, or indirect) user interaction.

If a suspend blocker is taken, because a key-press has to trickle up to userspace, it is because of the user.

If a call comes in, a suspend blocker is taken, because the user wants to receive incomming calls.

So suspend blockers are always a hint to the kernel, that the action is "on behalf of the user" and it is therefore ok to not suspend the device?

Quoted 10 lines

Quoted 9 lines

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

OK.

Good. I got this right at least.

Quoted 10 lines

Quoted 4 lines

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be annotated.

The applications interacting with the user rely on other parts of the system to block suspend then.

So it is (in general) not the application which determines if the user interacts, but other sources (like input-drivers) and possible a timeout?

Quoted 8 lines

Quoted 7 lines

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

Quoted 2 lines

If nothing blocks suspend. The reason to block suspend does not have to be direct user interaction.

But couldn't you say, that the suspend blockers are always due to the user? Or is this too narrow?  I mean we talk about a device here. And the device's purpose is it to serve the user. So it might be better to
say: suspend blockers annotate if a task is needed to fullfill the devices purpose?

It is an easy to understand concept if one says, the device suspends if it has nothing to do to further the cause.

I really want to get to a well expressed definition. suspend blockers block suspend. Shure. Buy why?

Quoted 5 lines

Quoted 4 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

Quoted 3 lines

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

I'm not shure. But then again, i'm not too familiar with the kernel. It sounds like it could save some duplication of effort to integrate suspend into the idle-framework. "Purpose-fulness" could be just another measure of "idle".

Quoted 20 lines

Quoted 20 lines

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Quoted 7 lines

Quoted 5 lines

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

I'm not sure what you mean.

Yeah. It's a "little bit" handwavy.

But the concept I have in mind:

       int what_good_would_it_be_to_go_into_this_state( state ) {
               /*

               cur_state = get_current_state(); benefit = ( get_power_per_time(cur_state)
                       - get_power_per_time(state) ) * get_expected_time_we_stay_there( state ); cost = get_transition_cost(cur_state,state); return benefit-cost;

               */
       }

and a constraint function:

       bool is_this_state_possible( state )
       {
               /*

               ret = true;
               cur_latency_requirement = get_cur_latency_req();
               ret &= (cur_latency_requirement >=state_latency_guaranty( state ) ); ret &= (some other QOS thingy);

               return ret;
               */
       }

And now, a loop would enter the state which has the biggest score and is possible at the time.

Afaik this is already implemented for c-states in the cpu_idle drivers?

2010/5/28 Florian Mickler <[email protected]>:

Quoted 4 lines

It sounds like it could save some duplication of effort to integrate suspend into the idle-framework. "Purpose-fulness" could be just another measure of "idle".

To me idle means that no threads are ready to run and no interrupts are pending.

I don't think we can plug suspend in as a cpu idle state. 1. we want to suspend even the cpu is not idle. 2. starting suspend will cause the cpu to not be idle.

2010/5/28 Florian Mickler <[email protected]>:

Quoted 4 lines

It sounds like it could save some duplication of effort to integrate suspend into the idle-framework. "Purpose-fulness" could be just another measure of "idle".

To me idle means that no threads are ready to run and no interrupts are pending.

I don't think we can plug suspend in as a cpu idle state. 1. we want to suspend even the cpu is not idle. 2. starting suspend will cause the cpu to not be idle.

Quoted 5 lines · On Fri, 28 May 2010 02:18:06 -0700 Arve Hjønnevåg <[email protected]> wrote:

Quoted 4 lines

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

Quoted 12 lines

That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the device.

Damn. I just want to put some abstract notion around this approach to power saving.

But one could say instead of "direct" interaction, that every time a suspend blocker is taken it is "on behalf of the user"?

So if a suspend blocker is taken, because a download is in progress, it is on behalf of (direct, or indirect) user interaction.

If a suspend blocker is taken, because a key-press has to trickle up to userspace, it is because of the user.

If a call comes in, a suspend blocker is taken, because the user wants to receive incomming calls.

So suspend blockers are always a hint to the kernel, that the action is "on behalf of the user" and it is therefore ok to not suspend the device?

Quoted 10 lines

Quoted 9 lines

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

OK.

Good. I got this right at least.

Quoted 10 lines

Quoted 4 lines

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be annotated.

The applications interacting with the user rely on other parts of the system to block suspend then.

So it is (in general) not the application which determines if the user interacts, but other sources (like input-drivers) and possible a timeout?

Quoted 8 lines

Quoted 7 lines

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

Quoted 2 lines

If nothing blocks suspend. The reason to block suspend does not have to be direct user interaction.

But couldn't you say, that the suspend blockers are always due to the user? Or is this too narrow?  I mean we talk about a device here. And the device's purpose is it to serve the user. So it might be better to
say: suspend blockers annotate if a task is needed to fullfill the devices purpose?

It is an easy to understand concept if one says, the device suspends if it has nothing to do to further the cause.

I really want to get to a well expressed definition. suspend blockers block suspend. Shure. Buy why?

Quoted 5 lines

Quoted 4 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

Quoted 3 lines

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

I'm not shure. But then again, i'm not too familiar with the kernel. It sounds like it could save some duplication of effort to integrate suspend into the idle-framework. "Purpose-fulness" could be just another measure of "idle".

Quoted 20 lines

Quoted 20 lines

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Quoted 7 lines

Quoted 5 lines

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

I'm not sure what you mean.

Yeah. It's a "little bit" handwavy.

But the concept I have in mind:

       int what_good_would_it_be_to_go_into_this_state( state ) {
               /*

               cur_state = get_current_state(); benefit = ( get_power_per_time(cur_state)
                       - get_power_per_time(state) ) * get_expected_time_we_stay_there( state ); cost = get_transition_cost(cur_state,state); return benefit-cost;

               */
       }

and a constraint function:

       bool is_this_state_possible( state )
       {
               /*

               ret = true;
               cur_latency_requirement = get_cur_latency_req();
               ret &= (cur_latency_requirement >=state_latency_guaranty( state ) ); ret &= (some other QOS thingy);

               return ret;
               */
       }

And now, a loop would enter the state which has the biggest score and is possible at the time.

Afaik this is already implemented for c-states in the cpu_idle drivers?

Quoted 4 lines

IMO, the whole concept is defining 2 modes of operation:

1. user interacts with the device (at least one suspend block active)
2. user doesn't interact with the device (zero suspend block active)

That is a somewhat odd way of looking at it. Yes we have two modes of operation, but an active suspend blocker does not mean that the user is interacting with the device. The way we use it, the "main" suspend blocker is active when the user interacts with the device (controlled by writing to /sys/power/state). All other suspend blockers are used to prevent suspend when user space has decided that the user is not interacting with the device. This includes blocking suspend in the kernel on key events which means the user actually is interacting with the device, even if user-space has not realized it yet. For other events, like an incoming phone call, we block suspend and make some noise with the hope that the user will start interacting with the device.

Quoted 9 lines

In case 1. the device wants _everything_ sheduled as normal (and save maximum possible power, i.e. runtime pm with every technology available now).

In case 2. we want nothing sheduled (and save maximum possible power, i.e. suspend)

OK.

Quoted 4 lines

And now, every application and every kernel driver annotates (on behalve of the user) if it (possibly) interacts with the user.

Applications that interact with the user do not normally need to block suspend. The user interacting with the device blocks suspend (just like with your desktop screen saver). Not every kernel driver needs to be annotated either, only potential wakeup events need to be annotated.

Quoted 7 lines

(Is this really the problematic bit, that userspace is giving the kernel hints? Or is it that the hints are called "blocker"?)

We can only enter mode 2, if _nothing_ (claims) to interact with the user.

If nothing blocks suspend. The reason to block suspend does not have to be direct user interaction.

Quoted 4 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 19 lines

Attributes of the idle states could be smth like this:

c3
       cost-to-transition-to-this-state: X
       powersavings-per-time: Y
       expected time we stay in this state: relative short, there is a timer sheduled
       suspend-blockers: ignored

suspend
       cost-to-transition-to-this-state: depends, how much drivers to suspend, how much processes to freeze, how much state to save
       powersavings-per-time: Y
       expected time we stay in this state: long, independent of sheduled timers
       suspend-blockers: must not be activated

Quoted 5 lines

Now all transitions and opportunistic suspend could be handled by the same algorithms.

Would this work?

I'm not sure what you mean.

Quoted 2 lines · Florian Mickler

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

2010/5/28 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 8 lines

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions).

Quoted 23 lines

2010/5/28 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 8 lines

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

Quoted 7 lines

I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions).

I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense.  If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started.  However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle.

Quoted 23 lines

2010/5/28 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 8 lines

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

Quoted 7 lines

I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions).

I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense.  If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started.  However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle.

2010/5/29 Rafael J. Wysocki <[email protected]>:

Quoted 32 lines · Arve Hjønnevåg

Quoted 23 lines

2010/5/28 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 8 lines

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

Quoted 7 lines

I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions).

Quoted 7 lines

I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense. If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started. However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle.

What about timers? When you suspend timers stop (otherwise it is just a deep-idle mode), and this could cause problems. Some drivers rely on timers if the hardware does not have a completion interrupt. It is not uncommon to see send command x then wait 200ms in a some hardware specs.

Quoted 41 lines

2010/5/29 Rafael J. Wysocki <[email protected]>:

Quoted 39 lines · Arve Hjønnevåg

Quoted 23 lines

2010/5/28 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 3 lines · Florian Mickler

Quoted 2 lines

On Thu, 27 May 2010 20:05:39 +0200 (CEST)
Thomas Gleixner <[email protected]> wrote:

...

Quoted 7 lines

Quoted 3 lines

To integrate this with the current way of doing things, i gathered it needs to be implemented as an idle-state that does the suspend()-call?

I think it is better no not confuse this with idle. Since initiating suspend will cause the system to become not-idle, I don't think is is beneficial to initiate suspend from idle.

Quoted 8 lines

It is, if the following two conditions hold simultaneously:

(a) Doing full system suspend is ultimately going to bring you more energy savings than the (presumably lowest) idle state you're currently in.

(b) You anticipate that the system will stay idle for a considerably long time such that it's worth suspending.

Quoted 7 lines

I still don't think this matters. If you are waiting for in interrupt that cannot wake you up from suspend, then idle is not an indicator that it is safe to enter suspend. I also don't think you can avoid any user-space suspend blockers by delaying suspend until the system goes idle since any page fault could cause it to go idle. Therefore I don't see a benefit in delaying suspend until idle when the last suspend blocker is released (it would only mask possible race conditions).

I wasn't referring to suspend blockers, but to the idea of initiating full system suspend from idle, which I still think makes sense.  If you are waiting for an interrupt that cannot wake you from suspend, then _obviously_ suspend should not be started.  However, if you're not waiting for such an interrupt and the (a) and (b) above hold, it makes sense to start suspend from idle.

Quoted 5 lines

What about timers? When you suspend timers stop (otherwise it is just a deep-idle mode), and this could cause problems. Some drivers rely on timers if the hardware does not have a completion interrupt. It is not uncommon to see send command x then wait 200ms in a some hardware specs.

QoS should be used in such cases.

2010/5/30 Rafael J. Wysocki <[email protected]>:

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend.

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

Now, under that assumption, I think it _generally_ is reasonable to make the system go into full suspend if everything (ie. CPUs and I/O) has been idle for sufficiently long time and there are no QoS requirements that aren't compatible with full system suspend.

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

2010/5/31 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Quoted 4 lines

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

Quoted 20 lines

2010/5/31 Rafael J. Wysocki <[email protected]>:

Quoted 17 lines · Arve Hjønnevåg

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

Quoted 5 lines

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle.

Quoted 20 lines

2010/5/31 Rafael J. Wysocki <[email protected]>:

Quoted 17 lines · Arve Hjønnevåg

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

Quoted 5 lines

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle.

2010/6/1 Thomas Gleixner <[email protected]>:

Quoted 27 lines · Arve Hjønnevåg

Quoted 25 lines

2010/5/31 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Quoted 4 lines

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

Quoted 3 lines

And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle.

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

Quoted 28 lines

2010/6/1 Thomas Gleixner <[email protected]>:

Quoted 27 lines · Arve Hjønnevåg

Quoted 25 lines

2010/5/31 Rafael J. Wysocki <[email protected]>:

Quoted 13 lines · Arve Hjønnevåg

Quoted 1 line

2010/5/30 Rafael J. Wysocki <[email protected]>:

...

Quoted 9 lines

I think it makes more sense to block suspend while wakeup events are pending than blocking it everywhere timers are used by code that could be called while handling wakeup events or other critical work. Also, even if you did block suspend everywhere timers where used you still have the race where a wakeup interrupt happens right after you decided to suspend. In other words, you still need to block suspend in all the same places as with the current opportunistic suspend code, so what is the benefit of delaying suspend until idle?

Quoted 4 lines

Assume for a while that you don't use suspend blockers, OK?  I realize you think that anything else doesn't make sense, but evidently some other people have that opinion about suspend blockers.

It sounded like you were suggesting that initiating suspend from idle would somehow avoid the race condition with wakeup events. All I'm saying is that you would need to block suspend in all the same places. If you don't care about ignoring wakeup events, then sure you can initiate suspend from idle.

Quoted 6 lines

Quoted 3 lines

And why should you miss a wakeup there ? If you get an interrupt in the transition, then you are not longer idle.

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

You still are addicted to the current suspend mechanism. :)

The whole point of doing it from idle in the form of a deep power state is to avoid the massive sh*tload of work which is neccesary to run the existing suspend code. But that needs runtime power management and tweaks to avoid your timers waking you, etc.

The mechanism you want to use is: suspend no matter what, like closing the lid of the laptop, but with a few tweaks around it:

  1) An interrupt on a wakeup source which comes in while the suspend code runs, i.e before you transitioned into wakeup mode, must abort / prevent suspend.

  2) Prevent another attempt to suspend before the event has been delivered and the apps have signaled that they have not longer any work to do.

  As a side effect you confine crappy apps with that mechanism in some way.

In the laptop case we do not want the tweaks as not going into suspend might set your backpack on fire.

If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to:

   1) crappy applications keeping the cpu away from idle
   2) timers firing

Would solving those two issues be sufficient for you or am I missing something ?

2010/6/2 Thomas Gleixner <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 3 lines

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

Quoted 2 lines

You still are addicted to the current suspend mechanism. :)

No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive.

Quoted 8 lines

If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to:

   1) crappy applications keeping the cpu away from idle
   2) timers firing

Would solving those two issues be sufficient for you or am I missing something ?

Solving those two is enough for current android phones, but it may not be enough for other android devices.

1 is not solvable (meaning we cannot fix all apps),

and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock.

Unrelated to Android, I also want to use opportunistic suspend on my desktop.

Quoted 9 lines

2010/6/2 Thomas Gleixner <[email protected]>:

Quoted 7 lines · Arve Hjønnevåg

Quoted 3 lines

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

You still are addicted to the current suspend mechanism. :)

Quoted 3 lines

No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive.

What prevents us from going into a disruptive mode from idle ? I don't see a reason - except crappy ACPI stuff, which I'm happy to ignore.

Quoted 6 lines

Quoted 6 lines

If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to:

   1) crappy applications keeping the cpu away from idle
   2) timers firing

Quoted 5 lines

Quoted 2 lines

Would solving those two issues be sufficient for you or am I missing something ?

Solving those two is enough for current android phones, but it may not be enough for other android devices.

In which way ? May not be enough is a pretty vague statement.

Quoted 2 lines

1 is not solvable (meaning we cannot fix all apps),

We can mitigate it with cgroups and confine crap there, i.e. force idle them.

Quoted 3 lines

and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock.

That's what I had in mind.

Quoted 2 lines

Unrelated to Android, I also want to use opportunistic suspend on my desktop.

I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro.

Quoted 9 lines

2010/6/2 Thomas Gleixner <[email protected]>:

Quoted 7 lines · Arve Hjønnevåg

Quoted 3 lines

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

You still are addicted to the current suspend mechanism. :)

Quoted 3 lines

No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive.

What prevents us from going into a disruptive mode from idle ? I don't see a reason - except crappy ACPI stuff, which I'm happy to ignore.

Quoted 6 lines

Quoted 6 lines

If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to:

   1) crappy applications keeping the cpu away from idle
   2) timers firing

Quoted 5 lines

Quoted 2 lines

Would solving those two issues be sufficient for you or am I missing something ?

Solving those two is enough for current android phones, but it may not be enough for other android devices.

In which way ? May not be enough is a pretty vague statement.

Quoted 2 lines

1 is not solvable (meaning we cannot fix all apps),

We can mitigate it with cgroups and confine crap there, i.e. force idle them.

Quoted 3 lines

and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock.

That's what I had in mind.

Quoted 2 lines

Unrelated to Android, I also want to use opportunistic suspend on my desktop.

I expect that intel/amd fixing their stuff is going to happen way before we sprinkled suspend blockers over a full featured desktop distro.

2010/6/2 Thomas Gleixner <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 3 lines

Because suspend itself causes you to not be idle you cannot abort suspend just because you are not idle anymore.

Quoted 2 lines

You still are addicted to the current suspend mechanism. :)

No I want you to stop confusing low power idle modes with suspend. I know how to enter low power modes from idle if that low power mode is not too disruptive.

Quoted 8 lines

If I understood you correctly then you can shutdown the CPU in idle completelty already, but that's not enough due to:

   1) crappy applications keeping the cpu away from idle
   2) timers firing

Would solving those two issues be sufficient for you or am I missing something ?

Solving those two is enough for current android phones, but it may not be enough for other android devices.

1 is not solvable (meaning we cannot fix all apps),

and 2 is difficult to fix since the periodic
work is useful while the device is actually in use. One possible way to solve 2 is to allow timers on a not-idle clock.

Unrelated to Android, I also want to use opportunistic suspend on my desktop.

No I want you to stop confusing low power idle modes with suspend.

Unrelated to
Android, I also want to use opportunistic suspend on my desktop.

Quoted 1 line

No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state.

(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already).

Quoted 2 lines

Unrelated to
Android, I also want to use opportunistic suspend on my desktop.

So you're going to sprinkle this suspend blocker shite all over regular userspace?

Why not instead work on getting apps to behave properly and idle when there's nothing to do?

After all, if you have the code to add suspend blockers into, you also have the means to fix it being stupid in the first place.

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 1 line

No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state.

No, idle is transparent, suspend is not.

Why would I add suspend blockers to the code I want to prevent running?

Quoted 8 lines · Arve Hjønnevåg

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 1 line

No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state.

No, idle is transparent, suspend is not.

Which is where the problem is, it should be.

Quoted 1 line

Why would I add suspend blockers to the code I want to prevent running?

Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there.

Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in.

This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface.

In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that.

On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra <[email protected]> wrote:

Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*)

But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. Why?

Quoted 3 lines

This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface.

A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox.

It is a hard problem. But we have _no way of deciding any of this in the kernel_

The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of "suspend blockers" scheme. Wouldn't it?

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Quoted 5 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Quoted 1 line

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Quoted 5 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Quoted 1 line

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Quoted 13 lines · Florian Mickler

Quoted 6 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

Quoted 13 lines · Florian Mickler

Quoted 6 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

Quoted 13 lines · Florian Mickler

Quoted 6 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

Quoted 9 lines · Peter Zijlstra

Quoted 8 lines · Florian Mickler

Quoted 1 line · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 8 lines

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

Exactly, and that's what applications in the N900 do. For this to work reliably, you need these notifications (network disconnected, screen off) to be easily accessible, and even transparent to the application writer.

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

We end up in exactly the same situation.

Quoted 9 lines · Peter Zijlstra

Quoted 8 lines · Florian Mickler

Quoted 1 line · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 8 lines

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

Exactly, and that's what applications in the N900 do. For this to work reliably, you need these notifications (network disconnected, screen off) to be easily accessible, and even transparent to the application writer.

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

We end up in exactly the same situation.

Quoted 12 lines · On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras…

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

Quoted 2 lines

We end up in exactly the same situation.

No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there."

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

Quoted 14 lines · Florian Mickler

Quoted 12 lines · On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras…

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

Quoted 5 lines

Quoted 2 lines

We end up in exactly the same situation.

No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there."

How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter.

How would you do that with the dynamic PM approach? At regular intervals you check for which applications are running (not idle).

Quoted 5 lines

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers.

Quoted 6 lines · On Sat, 5 Jun 2010 23:06:03 +0300 Felipe Contreras…

How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter.

How would you do that with the dynamic PM approach? At regular intervals you check for which applications are running (not idle).

IIRC, the patches discussed have debugging infrastructure in them. The kernel does the accounting.

Quoted 5 lines

Quoted 4 lines

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

Quoted 4 lines

So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers.

If you think a little about it, it is. Because if the app wouldn't be usable at all, the bug wouldn't get fixed because the user wouldn't use it. Or not?

Quoted 6 lines · On Sat, 5 Jun 2010 23:06:03 +0300 Felipe Contreras…

How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter.

How would you do that with the dynamic PM approach? At regular intervals you check for which applications are running (not idle).

IIRC, the patches discussed have debugging infrastructure in them. The kernel does the accounting.

Quoted 5 lines

Quoted 4 lines

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

Quoted 4 lines

So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers.

If you think a little about it, it is. Because if the app wouldn't be usable at all, the bug wouldn't get fixed because the user wouldn't use it. Or not?

Quoted 14 lines · Florian Mickler

Quoted 12 lines · On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras…

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

Quoted 5 lines

Quoted 2 lines

We end up in exactly the same situation.

No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there."

How would such stats be calculated? I presume at regular intervals you check which applications are holding suspend blockers and increase a counter.

How would you do that with the dynamic PM approach? At regular intervals you check for which applications are running (not idle).

Quoted 5 lines

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

So the difference is between removing the app, and making it run crappy. I don't think that's a strong argument in favor of suspend blockers.

Quoted 12 lines · On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras…

I don't think the suspend blockers solve much. A bad application will behave bad on any system. Suppose somebody decides to port Firefox to Android, and forgets to listen to the screen off event (bad on Android or Maemo), however, notices the application behaves very badly, so by googling finds these suspend blockers, and enables them all the time the application runs.

When the user install the application, will be greeted by a warning "This application might break PM, do you want to enable suspend blockers?" (or whatever), as any typical user would do, will press Yes (whatever).

Quoted 2 lines

We end up in exactly the same situation.

No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there."

The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent.

Quoted 13 lines · Florian Mickler

Quoted 6 lines · On Thu, 03 Jun 2010 09:40:02 +0200 Peter Zijlstra <[email protected]> wrote:

Same for firefox, you can teach it to not render animated gifs and run javascript for invisible tabs, and once the screen-saver kicks in, nothing is visible (and with X telling apps their window is visible or not it knows), so it should go idle all of its own.

Fix the friggin apps, don't kludge with freezing.

Of course programs should be as smart as possible. But that is an orthogonal problem.

Quoted 3 lines

Suppose firefox were fixed. It still needs to fetch my rss feeds every minute, because I'm sad if it doesn't. It just can't be fixed at the application level.

Sure it can, why would it need to fetch RSS feeds when the screen is off and nobody could possible see the result? So you can stop the timer when you know the window isn't visible or alternatively when the screensaver is active, I think most desktops have notification of that as well.

On Wed, 02 Jun 2010 12:21:28 +0200
Peter Zijlstra <[email protected]> wrote:

Do you switch your pc on and off manually? Sometimes? Really? (if not, you are probably a kernel hacker *g*)

But the rest are usecases that are similar to the suspend-blocker usecases. You know that you are not using the machine and going through the pain to shut down your machine. You have to do it manually. Why?

Quoted 3 lines

This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface.

A userspace daemon could keep track of what applications can be ignored. The wordprocessor probably should not keep the system busy. As well as a running firefox.

It is a hard problem. But we have _no way of deciding any of this in the kernel_

The problem is there independently of suspend blockers. If the system can suspend with network up, then you shure as hell want to suspend even if the network is up. So it would actually be a reason for any kind of "suspend blockers" scheme. Wouldn't it?

Quoted 8 lines · Arve Hjønnevåg

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 1 line

No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state.

No, idle is transparent, suspend is not.

Which is where the problem is, it should be.

Quoted 1 line

Why would I add suspend blockers to the code I want to prevent running?

Because what you want might not be what others want. Suppose you're fine with your torrent client/irc client/etc.. to loose their network connection when you're not behind your desktop so you don't add suspend blockers there.

Me, I'd be ready to administer physical violence if either of those lost their connections when I wasn't around to keep the screen-saver from kicking in.

This leads to having to sprinkle magic dust (and lots of config options) all over userspace. Something that gets esp interesting with only a boolean interface.

In the example above, having an active net connection would prevent my desktop from suspending, but what if another platform can maintain net connections while suspended? Do we then end up with arch specific code in the net-stack? I'm sure DaveM would love that.

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 5 lines · Arve Hjønnevåg

Quoted 1 line

No I want you to stop confusing low power idle modes with suspend.

I think it is you who is confused. For power management purposes suspend is nothing more but a deep idle state.

No, idle is transparent, suspend is not.

Why would I add suspend blockers to the code I want to prevent running?

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 3 lines

(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already).

I don't think it is realistic to drop support for all existing hardware.

Quoted 5 lines

Quoted 2 lines

Unrelated to
Android, I also want to use opportunistic suspend on my desktop.

So you're going to sprinkle this suspend blocker shite all over regular userspace?

I have said several times, that regular user-space will not need to be modified to maintain their current behavior.

2010/6/2 Arve Hjønnevåg <[email protected]>:

Quoted 6 lines

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 3 lines

(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already).

I don't think it is realistic to drop support for all existing hardware.

We are talking about mainline here, there's no support for suspend blockers, so nothing is dropped.

In the mind of everybody, suspend blockers is for opportunistic suspend, which only makes sense on sensible hw (not current x86). So in the mind of everybody, x86 should be out of scope for the analysis of suspend blockers.

Are you seriously suggesting that one of the strong arguments in favor of suspend blockers is x86 usage (nobody agrees)? If not, then drop it.

If I enable suspend blockers on my laptop, I have to modify my user-space. Otherwise my system will behave horribly.

Quoted 11 lines · On Sat, 5 Jun 2010 20:44:24 +0300 Felipe Contreras…

2010/6/2 Arve Hjønnevåg <[email protected]>:

Quoted 6 lines

2010/6/2 Peter Zijlstra <[email protected]>:

Quoted 3 lines

(and please don't mention @#$@ up x86 ACPI again, Intel knows, they're fixing it, get over it already).

I don't think it is realistic to drop support for all existing hardware.

We are talking about mainline here, there's no support for suspend blockers, so nothing is dropped.

Quoted 8 lines

In the mind of everybody, suspend blockers is for opportunistic suspend, which only makes sense on sensible hw (not current x86). So in the mind of everybody, x86 should be out of scope for the analysis of suspend blockers.

Are you seriously suggesting that one of the strong arguments in favor of suspend blockers is x86 usage (nobody agrees)? If not, then drop it.

I think they have an advantage over the 30-minute-screensaver-then-suspend that current desktops do. Because you can define what keeps the system up. I.e. the screensaver/powermanager is not limited to keyboard- and mouse-inactivity.

Quoted 3 lines

If I enable suspend blockers on my laptop, I have to modify my user-space. Otherwise my system will behave horribly.

In the simplest case you have a shell script which takes a suspend blocker and reads from stdinput. When you write "mem" to it, it releases the suspend blocker and acquires it back again. Voila, forced suspend reimplemented on top of opportunistic suspend.

That wasn't hard, was it?

Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers.

Quoted 8 lines · On Sat, 5 Jun 2010 23:26:27 +0300 Felipe Contreras…

Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers.

A solution for the desktop to deprecate having to shut down the machine would not be that bad, wouldn;t it? (Why have I to shut down my machine anyway?)

In my opinion such a decision (when to shutdown) has to be guided by userspace knowledge.
Future x86 hardware is to be fixed (as I read in this discussion), so using suspend blockers could be the tool of choice.

But alright. Let's be a little bit more focused on the present situation:

1) There currently is no other solution.

2) It is a first stepping stone to bringing android to mainline.

3) Any "perfect" solution will emerge anyway. As there are so many people with so strong opinions engaged in this discussion, I'm confident.

4) If there is a better solution, android will shurely adapt it as soon as it is there.

Stop that advertising campaing already.

No thanks,

tglx

Quoted 1 line · On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) Thomas Gleixner <[email protected]>…

Stop that advertising campaing already.

Stop advertising that there is no problem.

Quoted 4 lines

No thanks,

tglx

Cheers,
Flo

(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering and not dismissing the problem. This was pointed at
Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")

Quoted 1 line · On Sat, 5 Jun 2010 23:24:40 +0200 (CEST) Thomas Gleixner <[email protected]>…

Stop that advertising campaing already.

Stop advertising that there is no problem.

Quoted 4 lines

No thanks,

tglx

Cheers,
Flo

(Sorry, crossfire. Caused
by you answering in the wrong subthread. I know that you are
engineering and not dismissing the problem. This was pointed at
Felipes "There is no problem"/"suspend blockers don't do what they are designed to do well")

Stop that advertising campaing already.

No thanks,

tglx

Quoted 8 lines · On Sat, 5 Jun 2010 23:26:27 +0300 Felipe Contreras…

Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers.

A solution for the desktop to deprecate having to shut down the machine would not be that bad, wouldn;t it? (Why have I to shut down my machine anyway?)

In my opinion such a decision (when to shutdown) has to be guided by userspace knowledge.
Future x86 hardware is to be fixed (as I read in this discussion), so using suspend blockers could be the tool of choice.

But alright. Let's be a little bit more focused on the present situation:

1) There currently is no other solution.

2) It is a first stepping stone to bringing android to mainline.

3) Any "perfect" solution will emerge anyway. As there are so many people with so strong opinions engaged in this discussion, I'm confident.

4) If there is a better solution, android will shurely adapt it as soon as it is there.

Supposing there's a perfect usage of suspend blockers from user-space on current x86 platforms (in theory Android would have that), is the benefit that big to consider this a strong argument in favor of suspend blockers? Considering the small amount of x86 platforms using Android (is there any?), the fact that nobody else will use suspend blockers, and that x86 is already being fixed (as mentioned many times before) so dynamic PM is possible, I don't think we should be considering current x86 at all for suspend blockers.