cpuidle: extend cpuidle and menu governor to handle dynamic states

On some SoC chips, HW resources may be in use during any particular idle period. As a consequence, the cpuidle states that the SoC is safe to enter can change from idle period to idle period. In addition, the latency and threshold of each cpuidle state can vary, depending on the operating condition when the CPU becomes idle, e.g. the current cpu frequency, the current state of the HW blocks, etc.

cpuidle core and the menu governor, in the current form, are geared towards cpuidle states that are static, i.e. the availabiltiy of the states, their latencies, their thresholds are non-changing during run time. cpuidle does not provide any hook that cpuidle drivers can use to adjust those values on the fly for the current idle period before the menu governor selects the target cpuidle state.

This patch extends cpuidle core and the menu governor to handle states that are dynamic. There are three additions in the patch and the patch maintains backwards-compatibility with existing cpuidle drivers.

1) add prepare() to struct cpuidle_device. A cpuidle driver can hook into the callback and cpuidle will call prepare() before calling the governor's select function. The callback gives the cpuidle driver a chance to update the dynamic information of the cpuidle states for the current idle period, e.g. state availability, latencies, thresholds, power values, etc.

2) add CPUIDLE_FLAG_IGNORE as one of the state flags. In the prepare() function, a cpuidle driver can set/clear the flag to indicate to the menu governor whether a cpuidle state should be ignored, i.e. not available, during the current idle period.

3) add power_specified bit to struct cpuidle_device. The menu governor currently assumes that the cpuidle states are arranged in the order of increasing latency, threshold, and power savings. This is true or can be made true for static states. Once the state parameters are dynamic, the latencies, thresholds, and power savings for the cpuidle states can increase or decrease by different amounts from idle period to idle period. So the assumption of increasing latency, threshold, and power savings from Cn to C(n+1) can no longer be guaranteed.

It can be straight forward to calculate the power consumption of each available state and to specify it in power_usage for the idle period. Using the power_usage fields, the menu governor then selects the state that has the lowest power consumption and that still satisfies all other critieria. The power_specified bit defaults to 0. For existing cpuidle drivers, cpuidle detects that power_specified is 0 and fills in a dummy set of power_usage values.

Signed-off-by Ai Li <[email protected]>

---
 drivers/cpuidle/cpuidle.c        |   13 +++++++++++++
 drivers/cpuidle/governors/menu.c |   22 +++++++++++++++-------
 include/linux/cpuidle.h          |    4 ++++
 3 files changed, 32 insertions(+), 7 deletions(-)

drivers/cpuidle/cpuidle.c +0 -0

index 1994885..7df8094 100644

drivers/cpuidle/governors/menu.c +11 -5

 	for (i = CPUIDLE_DRIVER_STATE_START; i < dev->state_count; i++) {
 		struct cpuidle_state *s = &dev->states[i];
 
+		if (s->flags & CPUIDLE_FLAG_IGNORE)
+			continue;
 		if (s->target_residency > data->predicted_us)
-			break;
+			continue;
 		if (s->exit_latency > latency_req)
-			break;
+			continue;
 		if (s->exit_latency * multiplier > data->predicted_us)
-			break;
-		data->exit_us = s->exit_latency;
-		data->last_state_idx = i;
+			continue;
+
+		if (s->power_usage < power_usage) {
+			power_usage = s->power_usage;
+			data->last_state_idx = i;
+			data->exit_us = s->exit_latency;
+		}
 	}
 
 	return data->last_state_idx;

include/linux/cpuidle.h +1 -0

index 55215cc..36ca972 100644
@@ -52,6 +52,7 @@ struct cpuidle_state {
 #define CPUIDLE_FLAG_SHALLOW	(0x20) /* low latency, minimal savings */
 #define CPUIDLE_FLAG_BALANCED	(0x40) /* medium latency, moderate savings */
 #define CPUIDLE_FLAG_DEEP	(0x80) /* high latency, large savings */
+#define CPUIDLE_FLAG_IGNORE	(0x100) /* ignore during this idle period */
 
 #define CPUIDLE_DRIVER_FLAGS_MASK (0xFFFF0000)
 

include/linux/cpuidle.h +2 -0

 	int			last_residency;

@@ -97,6 +99,8 @@ struct cpuidle_device {
 	struct completion	kobj_unregister;
 	void			*governor_data;
 	struct cpuidle_state	*safe_state;
+
+	int (*prepare)		(struct cpuidle_device *dev);
 };
 
 DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);

On some SoC chips, HW resources may be in use during any particular idle period. As a consequence, the cpuidle states that the SoC is safe to enter can change from idle period to idle period. In addition, the latency and threshold of each cpuidle state can vary, depending on the operating condition when the CPU becomes idle, e.g. the current cpu frequency, the current state of the HW blocks, etc.

cpuidle core and the menu governor, in the current form, are geared towards cpuidle states that are static, i.e. the availabiltiy of the states, their latencies, their thresholds are non-changing during run time. cpuidle does not provide any hook that cpuidle drivers can use to adjust those values on the fly for the current idle period before the menu governor selects the target cpuidle state.

This patch extends cpuidle core and the menu governor to handle states that are dynamic. There are three additions in the patch and the patch maintains backwards-compatibility with existing cpuidle drivers.

1) add prepare() to struct cpuidle_device. A cpuidle driver can hook into the callback and cpuidle will call prepare() before calling the governor's select function. The callback gives the cpuidle driver a chance to update the dynamic information of the cpuidle states for the current idle period, e.g. state availability, latencies, thresholds, power values, etc.

2) add CPUIDLE_FLAG_IGNORE as one of the state flags. In the prepare() function, a cpuidle driver can set/clear the flag to indicate to the menu governor whether a cpuidle state should be ignored, i.e. not available, during the current idle period.

3) add power_specified bit to struct cpuidle_device. The menu governor currently assumes that the cpuidle states are arranged in the order of increasing latency, threshold, and power savings. This is true or can be made true for static states. Once the state parameters are dynamic, the latencies, thresholds, and power savings for the cpuidle states can increase or decrease by different amounts from idle period to idle period. So the assumption of increasing latency, threshold, and power savings from Cn to C(n+1) can no longer be guaranteed.

It can be straight forward to calculate the power consumption of each available state and to specify it in power_usage for the idle period. Using the power_usage fields, the menu governor then selects the state that has the lowest power consumption and that still satisfies all other critieria. The power_specified bit defaults to 0. For existing cpuidle drivers, cpuidle detects that power_specified is 0 and fills in a dummy set of power_usage values.

Signed-off-by Ai Li <[email protected]>

---
 drivers/cpuidle/cpuidle.c        |   13 +++++++++++++
 drivers/cpuidle/governors/menu.c |   22 +++++++++++++++-------
 include/linux/cpuidle.h          |    4 ++++
 3 files changed, 32 insertions(+), 7 deletions(-)

drivers/cpuidle/cpuidle.c +0 -0

index 1994885..7df8094 100644

drivers/cpuidle/governors/menu.c +11 -5

 	for (i = CPUIDLE_DRIVER_STATE_START; i < dev->state_count; i++) {
 		struct cpuidle_state *s = &dev->states[i];
 
+		if (s->flags & CPUIDLE_FLAG_IGNORE)
+			continue;
 		if (s->target_residency > data->predicted_us)
-			break;
+			continue;
 		if (s->exit_latency > latency_req)
-			break;
+			continue;
 		if (s->exit_latency * multiplier > data->predicted_us)
-			break;
-		data->exit_us = s->exit_latency;
-		data->last_state_idx = i;
+			continue;
+
+		if (s->power_usage < power_usage) {
+			power_usage = s->power_usage;
+			data->last_state_idx = i;
+			data->exit_us = s->exit_latency;
+		}
 	}
 
 	return data->last_state_idx;

include/linux/cpuidle.h +1 -0

index 55215cc..36ca972 100644
@@ -52,6 +52,7 @@ struct cpuidle_state {
 #define CPUIDLE_FLAG_SHALLOW	(0x20) /* low latency, minimal savings */
 #define CPUIDLE_FLAG_BALANCED	(0x40) /* medium latency, moderate savings */
 #define CPUIDLE_FLAG_DEEP	(0x80) /* high latency, large savings */
+#define CPUIDLE_FLAG_IGNORE	(0x100) /* ignore during this idle period */
 
 #define CPUIDLE_DRIVER_FLAGS_MASK (0xFFFF0000)
 

include/linux/cpuidle.h +2 -0

 	int			last_residency;

@@ -97,6 +99,8 @@ struct cpuidle_device {
 	struct completion	kobj_unregister;
 	void			*governor_data;
 	struct cpuidle_state	*safe_state;
+
+	int (*prepare)		(struct cpuidle_device *dev);
 };
 
 DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

Quoted 9 lines · On Thu, 29 Jul 2010 13:15:29 -0600 Ai Li <[email protected]> wrote:

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

grumble.

Well, please at least explain all this in the changelogs when you send out the next version.

Quoted 5 lines · Ai Li

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

Quoted 3 lines

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

We can just re-submit this patch with our msm cpuidle code when that is finished.

Quoted 9 lines · On Thu, 29 Jul 2010 13:15:29 -0600 Ai Li <[email protected]> wrote:

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

grumble.

Well, please at least explain all this in the changelogs when you send out the next version.

Quoted 5 lines · Ai Li

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

Quoted 3 lines

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.

We can just re-submit this patch with our msm cpuidle code when that is finished.

Quoted 2 lines · Andrew Morton

I'd be reluctant to merge this code without also having code which uses it. As it is the change is useless and untestable.

We have local code in the arch/arm/mach-msm branch that uses the new cpuidle code. We are still developing and testing the MSM patches, and hope to upstream them in a few weeks.