Skip to contentSkip to conversation

ACPI, CPU_IDLE: Add more information about C-states

PATCH Applied Venki Pallipadi 2 participants 7 messages Feb 12, 2008 – Feb 15, 2008

Subsystems (4)
x86 ACPI ACPI component architecture (acpica) CPU idle time management framework
lore
Share & tools
lore

Venki Pallipadi

author
#0 lore raw

PATCH 1/1 ACPI, CPU_IDLE: Add more information about C-states

From: Venkatesh Pallipadi <[email protected]>

Add a new sysfs entry under cpuidle states. desc - can be used by driver to communicate to userspace any specific information about the state. This helps in identifying the exact hardware C-states behind the ACPI C-state definition.

Idea is to export this through powertop, which will help to map the C-state reported by powertop to actual hardware C-state.

Signed-off-by Venkatesh Pallipadi <[email protected]>
arch/x86/kernel/acpi/cstate.c +2 -0
Index: linux-2.6.25-rc/arch/x86/kernel/acpi/cstate.c
===================================================================
@@ -126,6 +126,8 @@ int acpi_processor_ffh_cstate_probe(unsi
 		printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
 		       "state\n", cx->type);
 	}
+	snprintf(cx->desc, ACPI_CX_DESC_LEN, "ACPI FFH INTEL MWAIT 0x%x",
+		 cx->address);
 
 out:
 	set_cpus_allowed(current, saved_mask);
drivers/acpi/processor_idle.c +11 -0
Index: linux-2.6.25-rc/drivers/acpi/processor_idle.c
===================================================================
@@ -917,11 +917,16 @@ static int acpi_processor_get_power_info
 				 * Otherwise, ignore this info and continue.
 				 */
 				cx.entry_method = ACPI_CSTATE_HALT;
+				snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI HLT");
 			} else {
 				continue;
 			}
+		} else {
+			snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI IOPORT 0x%x",
+				 cx.address);
 		}
 
+
 		obj = &(element->package.elements[2]);
 		if (obj->type != ACPI_TYPE_INTEGER)
 			continue;

@@ -1620,6 +1625,11 @@ static int acpi_processor_setup_cpuidle(
 		return -EINVAL;
 	}
 
+	for (i = 0; i < CPUIDLE_STATE_MAX; i++) {
+		dev->states[i].name[0] = '\0';
+		dev->states[i].desc[0] = '\0';
+	}
+
 	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER && i <= max_cstate; i++) {
 		cx = &pr->power.states[i];
 		state = &dev->states[count];

@@ -1636,6 +1646,7 @@ static int acpi_processor_setup_cpuidle(
 		cpuidle_set_statedata(state, cx);
 
 		snprintf(state->name, CPUIDLE_NAME_LEN, "C%d", i);
+		strncpy(state->desc, cx->desc, CPUIDLE_DESC_LEN);
 		state->exit_latency = cx->latency;
 		state->target_residency = cx->latency * 6;
 		state->power_usage = cx->power;
drivers/cpuidle/sysfs.c +11 -3
Index: linux-2.6.25-rc/drivers/cpuidle/sysfs.c
===================================================================
@@ -218,16 +218,23 @@ static ssize_t show_state_##_name(struct
 	return sprintf(buf, "%u\n", state->_name);\
 }
 
-static ssize_t show_state_name(struct cpuidle_state *state, char *buf)
-{
-	return sprintf(buf, "%s\n", state->name);
+#define define_show_state_str_function(_name) \
+static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) \
+{ \
+	if (state->_name[0] == '\0')\
+		return sprintf(buf, "<null>\n");\
+	return sprintf(buf, "%s\n", state->_name);\
 }
 
 define_show_state_function(exit_latency)
 define_show_state_function(power_usage)
 define_show_state_function(usage)
 define_show_state_function(time)
+define_show_state_str_function(name)
+define_show_state_str_function(desc)
+
 define_one_state_ro(name, show_state_name);
+define_one_state_ro(desc, show_state_desc);
 define_one_state_ro(latency, show_state_exit_latency);
 define_one_state_ro(power, show_state_power_usage);
 define_one_state_ro(usage, show_state_usage);

@@ -235,6 +242,7 @@ define_one_state_ro(time, show_state_tim
 
 static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_name.attr,
+	&attr_desc.attr,
 	&attr_latency.attr,
 	&attr_power.attr,
 	&attr_usage.attr,
include/acpi/processor.h +6 -3
Index: linux-2.6.25-rc/include/acpi/processor.h
===================================================================
@@ -32,9 +32,11 @@
 #define DOMAIN_COORD_TYPE_SW_ANY	0xfd
 #define DOMAIN_COORD_TYPE_HW_ALL	0xfe
 
-#define ACPI_CSTATE_SYSTEMIO	(0)
-#define ACPI_CSTATE_FFH		(1)
-#define ACPI_CSTATE_HALT	(2)
+#define ACPI_CSTATE_SYSTEMIO	0
+#define ACPI_CSTATE_FFH		1
+#define ACPI_CSTATE_HALT	2
+
+#define ACPI_CX_DESC_LEN	32
 
 /* Power Management */
 

@@ -74,6 +76,7 @@ struct acpi_processor_cx {
 	u64 time;
 	struct acpi_processor_cx_policy promotion;
 	struct acpi_processor_cx_policy demotion;
+	char desc[ACPI_CX_DESC_LEN];
 };
 
 struct acpi_processor_power {
include/linux/cpuidle.h +2 -0
Index: linux-2.6.25-rc/include/linux/cpuidle.h
===================================================================
@@ -19,6 +19,7 @@
 
 #define CPUIDLE_STATE_MAX	8
 #define CPUIDLE_NAME_LEN	16
+#define CPUIDLE_DESC_LEN	32
 
 struct cpuidle_device;
 

@@ -29,6 +30,7 @@ struct cpuidle_device;
 
 struct cpuidle_state {
 	char		name[CPUIDLE_NAME_LEN];
+	char		desc[CPUIDLE_DESC_LEN];
 	void		*driver_data;
 
 	unsigned int	flags;
drivers/cpuidle/cpuidle.c +2 -1
Index: linux-2.6.25-rc/drivers/cpuidle/cpuidle.c
===================================================================
@@ -219,7 +219,8 @@ static void poll_idle_init(struct cpuidl
 
 	cpuidle_set_statedata(state, NULL);
 
-	snprintf(state->name, CPUIDLE_NAME_LEN, "C0 (poll idle)");
+	snprintf(state->name, CPUIDLE_NAME_LEN, "C0");
+	snprintf(state->desc, CPUIDLE_DESC_LEN, "CPUIDLE CORE POLL IDLE");
 	state->exit_latency = 0;
 	state->target_residency = 0;
 	state->power_usage = -1;
reviewer Applied
#1 lore raw

applied

thanks,
-len

Quoted 171 lines · Venki Pallipadi

From: Venkatesh Pallipadi <[email protected]>

Add a new sysfs entry under cpuidle states. desc - can be used by driver to communicate to userspace any specific information about the state. This helps in identifying the exact hardware C-states behind the ACPI C-state definition.

Idea is to export this through powertop, which will help to map the C-state reported by powertop to actual hardware C-state.

Signed-off-by Venkatesh Pallipadi <[email protected]>

Index: linux-2.6.25-rc/arch/x86/kernel/acpi/cstate.c
===================================================================

arch/x86/kernel/acpi/cstate.c +2 -0
@@ -126,6 +126,8 @@ int acpi_processor_ffh_cstate_probe(unsi
 		printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
 		       "state\n", cx->type);
 	}
+	snprintf(cx->desc, ACPI_CX_DESC_LEN, "ACPI FFH INTEL MWAIT 0x%x",
+		 cx->address);
 
 out:
 	set_cpus_allowed(current, saved_mask);

Index: linux-2.6.25-rc/drivers/acpi/processor_idle.c
===================================================================

drivers/acpi/processor_idle.c +11 -0
@@ -917,11 +917,16 @@ static int acpi_processor_get_power_info
 				 * Otherwise, ignore this info and continue.
 				 */
 				cx.entry_method = ACPI_CSTATE_HALT;
+				snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI HLT");
 			} else {
 				continue;
 			}
+		} else {
+			snprintf(cx.desc, ACPI_CX_DESC_LEN, "ACPI IOPORT 0x%x",
+				 cx.address);
 		}
 
+
 		obj = &(element->package.elements[2]);
 		if (obj->type != ACPI_TYPE_INTEGER)
 			continue;

@@ -1620,6 +1625,11 @@ static int acpi_processor_setup_cpuidle(
 		return -EINVAL;
 	}
 
+	for (i = 0; i < CPUIDLE_STATE_MAX; i++) {
+		dev->states[i].name[0] = '\0';
+		dev->states[i].desc[0] = '\0';
+	}
+
 	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER && i <= max_cstate; i++) {
 		cx = &pr->power.states[i];
 		state = &dev->states[count];

@@ -1636,6 +1646,7 @@ static int acpi_processor_setup_cpuidle(
 		cpuidle_set_statedata(state, cx);
 
 		snprintf(state->name, CPUIDLE_NAME_LEN, "C%d", i);
+		strncpy(state->desc, cx->desc, CPUIDLE_DESC_LEN);
 		state->exit_latency = cx->latency;
 		state->target_residency = cx->latency * 6;
 		state->power_usage = cx->power;

Index: linux-2.6.25-rc/drivers/cpuidle/sysfs.c
===================================================================

drivers/cpuidle/sysfs.c +11 -3
@@ -218,16 +218,23 @@ static ssize_t show_state_##_name(struct
 	return sprintf(buf, "%u\n", state->_name);\
 }
 
-static ssize_t show_state_name(struct cpuidle_state *state, char *buf)
-{
-	return sprintf(buf, "%s\n", state->name);
+#define define_show_state_str_function(_name) \
+static ssize_t show_state_##_name(struct cpuidle_state *state, char *buf) \
+{ \
+	if (state->_name[0] == '\0')\
+		return sprintf(buf, "<null>\n");\
+	return sprintf(buf, "%s\n", state->_name);\
 }
 
 define_show_state_function(exit_latency)
 define_show_state_function(power_usage)
 define_show_state_function(usage)
 define_show_state_function(time)
+define_show_state_str_function(name)
+define_show_state_str_function(desc)
+
 define_one_state_ro(name, show_state_name);
+define_one_state_ro(desc, show_state_desc);
 define_one_state_ro(latency, show_state_exit_latency);
 define_one_state_ro(power, show_state_power_usage);
 define_one_state_ro(usage, show_state_usage);

@@ -235,6 +242,7 @@ define_one_state_ro(time, show_state_tim
 
 static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_name.attr,
+	&attr_desc.attr,
 	&attr_latency.attr,
 	&attr_power.attr,
 	&attr_usage.attr,

Index: linux-2.6.25-rc/include/acpi/processor.h
===================================================================

include/acpi/processor.h +6 -3
@@ -32,9 +32,11 @@
 #define DOMAIN_COORD_TYPE_SW_ANY	0xfd
 #define DOMAIN_COORD_TYPE_HW_ALL	0xfe
 
-#define ACPI_CSTATE_SYSTEMIO	(0)
-#define ACPI_CSTATE_FFH		(1)
-#define ACPI_CSTATE_HALT	(2)
+#define ACPI_CSTATE_SYSTEMIO	0
+#define ACPI_CSTATE_FFH		1
+#define ACPI_CSTATE_HALT	2
+
+#define ACPI_CX_DESC_LEN	32
 
 /* Power Management */
 

@@ -74,6 +76,7 @@ struct acpi_processor_cx {
 	u64 time;
 	struct acpi_processor_cx_policy promotion;
 	struct acpi_processor_cx_policy demotion;
+	char desc[ACPI_CX_DESC_LEN];
 };
 
 struct acpi_processor_power {

Index: linux-2.6.25-rc/include/linux/cpuidle.h
===================================================================

include/linux/cpuidle.h +2 -0
@@ -19,6 +19,7 @@
 
 #define CPUIDLE_STATE_MAX	8
 #define CPUIDLE_NAME_LEN	16
+#define CPUIDLE_DESC_LEN	32
 
 struct cpuidle_device;
 

@@ -29,6 +30,7 @@ struct cpuidle_device;
 
 struct cpuidle_state {
 	char		name[CPUIDLE_NAME_LEN];
+	char		desc[CPUIDLE_DESC_LEN];
 	void		*driver_data;
 
 	unsigned int	flags;

Index: linux-2.6.25-rc/drivers/cpuidle/cpuidle.c
===================================================================

drivers/cpuidle/cpuidle.c +2 -2
@@ -219,7 +219,8 @@ static void poll_idle_init(struct cpuidl
 
 	cpuidle_set_statedata(state, NULL);
 
-	snprintf(state->name, CPUIDLE_NAME_LEN, "C0 (poll idle)");
+	snprintf(state->name, CPUIDLE_NAME_LEN, "C0");
+	snprintf(state->desc, CPUIDLE_DESC_LEN, "CPUIDLE CORE POLL IDLE");
 	state->exit_latency = 0;
 	state->target_residency = 0;
 	state->power_usage = -1;
-

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

reviewer
#2 lore raw

I'm confused by state0 -- why are usage and time non-zero -- is this due to some residency there during initialization?

I don't know if I like the looks of 2^32 - 1 as the power number...

-Len

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec
states:
    C1:                  type[C1] promotion[--] demotion[--] latency[001] usage[00000000] duration[00000000000000000000]
    C2:                  type[C2] promotion[--] demotion[--] latency[001] usage[00000161] duration[00000000000000018522]
    C3:                  type[C3] promotion[--] demotion[--] latency[017] usage[00088238] duration[00000000002957934702]

[root@t61 cpuidle]# grep . */*
state0/desc:CPUIDLE CORE POLL IDLE
state0/latency:0
state0/name:C0
state0/power:4294967295
state0/time:11623
state0/usage:6
state1/desc:ACPI FFH INTEL MWAIT 0x0
state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/desc:ACPI FFH INTEL MWAIT 0x10
state2/latency:1
state2/name:C2
state2/power:500
state2/time:5104
state2/usage:163
state3/desc:ACPI FFH INTEL MWAIT 0x20
state3/latency:17
state3/name:C3
state3/power:250
state3/time:830738297
state3/usage:89280

of course this isnt' new with this patch -- 2.6.25-rc1 looks as below:

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec
states:
    C1:                  type[C1] promotion[--] demotion[--] latency[001] usage[00000000] duration[00000000000000000000]
    C2:                  type[C2] promotion[--] demotion[--] latency[001] usage[00000202] duration[00000000000000028172]
    C3:                  type[C3] promotion[--] demotion[--] latency[017] usage[00026011] duration[00000000000264174466]

[root@t61 cpuidle]# grep . */*
state0/latency:0
state0/name:C0 (poll idle)
state0/power:4294967295
state0/time:35713
state0/usage:6
state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/latency:1
state2/name:C2
state2/power:500
state2/time:7771
state2/usage:203
state3/latency:17
state3/name:C3
state3/power:250
state3/time:74950731
state3/usage:26286

and 2.6.24 showed no C0, as expected.

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000 usec
states:
    C1:                  type[C1] promotion[--] demotion[--] latency[001] usage[00000030] duration[00000000000000000000]
    C2:                  type[C2] promotion[--] demotion[--] latency[001] usage[00000714] duration[00000000000000531448]
    C3:                  type[C3] promotion[--] demotion[--] latency[017] usage[00020563] duration[00000000000168147357]

[root@t61 cpuidle]# grep . */*
state0/latency:1
state0/name:C1
state0/power:1000
state0/time:0
state0/usage:30
state1/latency:1
state1/name:C2
state1/power:500
state1/time:148317
state1/usage:719
state2/latency:17
state2/name:C3
state2/power:250
state2/time:48238649
state2/usage:21034
[root@t61 cpuidle]#

author
#3 lore raw

'usage' is a counter that counts every time we get into poll_idle routine. I also try to keep track of time spent in poll_idle, until need_resched sends us out. That time is accumulated in 'time'. Just have those to be consistent with other state and to be sure that powertop kind of tools wont get confused.

I agree with the 'power' number. I did not like that 4294967295 there. But, I had to put some number higher than other C-states, maximum possible seemed logical. May be I can change the sysfs interface to print <NULL> or something like that for power?

Thanks,
Venki

Quoted 121 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Thursday, February 14, 2008 12:09 AM
To: Pallipadi, Venkatesh
Cc: [email protected]
Subject: Re: [PATCH] ACPI, CPU_IDLE: Add more information about C-states

I'm confused by state0 -- why are usage and time non-zero -- is this due to some residency there during initialization?

I don't know if I like the looks of 2^32 - 1 as the power number...

-Len

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000161] duration[00000000000000018522]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00088238] duration[00000000002957934702] [root@t61 cpuidle]# grep . */*
state0/desc:CPUIDLE CORE POLL IDLE state0/latency:0
state0/name:C0
state0/power:4294967295
state0/time:11623
state0/usage:6
state1/desc:ACPI FFH INTEL MWAIT 0x0 state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/desc:ACPI FFH INTEL MWAIT 0x10 state2/latency:1
state2/name:C2
state2/power:500
state2/time:5104
state2/usage:163
state3/desc:ACPI FFH INTEL MWAIT 0x20 state3/latency:17
state3/name:C3
state3/power:250
state3/time:830738297
state3/usage:89280

of course this isnt' new with this patch -- 2.6.25-rc1 looks as below:

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000202] duration[00000000000000028172]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00026011] duration[00000000000264174466] [root@t61 cpuidle]# grep . */*
state0/latency:0
state0/name:C0 (poll idle)
state0/power:4294967295
state0/time:35713
state0/usage:6
state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/latency:1
state2/name:C2
state2/power:500
state2/time:7771
state2/usage:203
state3/latency:17
state3/name:C3
state3/power:250
state3/time:74950731
state3/usage:26286

and 2.6.24 showed no C0, as expected.

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000030] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000714] duration[00000000000000531448]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00020563] duration[00000000000168147357] [root@t61 cpuidle]# grep . */*
state0/latency:1
state0/name:C1
state0/power:1000
state0/time:0
state0/usage:30
state1/latency:1
state1/name:C2
state1/power:500
state1/time:148317
state1/usage:719
state2/latency:17
state2/name:C3
state2/power:250
state2/time:48238649
state2/usage:21034
[root@t61 cpuidle]#

reviewer
#4 lore raw
Quoted 6 lines · Venkatesh

'usage' is a counter that counts every time we get into poll_idle routine. I also try to keep track of time spent in poll_idle, until need_resched sends us out. That time is accumulated in 'time'. Just have those to be consistent with other state and to be sure that powertop kind of tools wont get confused.

yes, the consistency is good.
But my question is when and why we enter poll_idle at all.

Quoted 4 lines

I agree with the 'power' number. I did not like that 4294967295 there. But, I had to put some number higher than other C-states, maximum possible seemed logical. May be I can change the sysfs interface to print <NULL> or something like that for power?

I dunno. Somehow I like 0 to signify an unknown quantity rather than a huge number. If somebody actually looks at it with a program, they're going to have to special case either of them, and 0 seems simpler.

thanks,
-Len

Quoted 115 lines
Quoted 114 lines

I'm confused by state0 -- why are usage and time non-zero -- is this due to some residency there during initialization?

I don't know if I like the looks of 2^32 - 1 as the power number...

-Len

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000161] duration[00000000000000018522]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00088238] duration[00000000002957934702] [root@t61 cpuidle]# grep . */*
state0/desc:CPUIDLE CORE POLL IDLE state0/latency:0
state0/name:C0
state0/power:4294967295
state0/time:11623
state0/usage:6
state1/desc:ACPI FFH INTEL MWAIT 0x0 state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/desc:ACPI FFH INTEL MWAIT 0x10 state2/latency:1
state2/name:C2
state2/power:500
state2/time:5104
state2/usage:163
state3/desc:ACPI FFH INTEL MWAIT 0x20 state3/latency:17
state3/name:C3
state3/power:250
state3/time:830738297
state3/usage:89280

of course this isnt' new with this patch -- 2.6.25-rc1 looks as below:

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000000000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000000] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000202] duration[00000000000000028172]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00026011] duration[00000000000264174466] [root@t61 cpuidle]# grep . */*
state0/latency:0
state0/name:C0 (poll idle)
state0/power:4294967295
state0/time:35713
state0/usage:6
state1/latency:1
state1/name:C1
state1/power:1000
state1/time:0
state1/usage:0
state2/latency:1
state2/name:C2
state2/power:500
state2/time:7771
state2/usage:203
state3/latency:17
state3/name:C3
state3/power:250
state3/time:74950731
state3/usage:26286

and 2.6.24 showed no C0, as expected.

[root@t61 cpuidle]# cat /proc/acpi/processor/CPU0/power

active state:            C0
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000 usec

states:
C1: type[C1] promotion[--] demotion[--]
latency[001] usage[00000030] duration[00000000000000000000]
C2: type[C2] promotion[--] demotion[--]
latency[001] usage[00000714] duration[00000000000000531448]
C3: type[C3] promotion[--] demotion[--]
latency[017] usage[00020563] duration[00000000000168147357] [root@t61 cpuidle]# grep . */*
state0/latency:1
state0/name:C1
state0/power:1000
state0/time:0
state0/usage:30
state1/latency:1
state1/name:C2
state1/power:500
state1/time:148317
state1/usage:719
state2/latency:17
state2/name:C3
state2/power:250
state2/time:48238649
state2/usage:21034
[root@t61 cpuidle]#

author
#5 lore raw
Quoted 12 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Thursday, February 14, 2008 12:41 PM
To: Pallipadi, Venkatesh
Cc: [email protected]
Subject: Re: [PATCH] ACPI, CPU_IDLE: Add more information about C-states

Quoted 1 line · Venkatesh
Quoted 8 lines
Quoted 5 lines

'usage' is a counter that counts every time we get into poll_idle routine. I also try to keep track of time spent in poll_idle, until need_resched sends us out. That time is accumulated in 'time'. Just have those to be consistent with other state and to be sure that powertop kind of tools wont get confused.

yes, the consistency is good.
But my question is when and why we enter poll_idle at all.

Ohh. Ok. May be the ladder governor used it for a while, before we switch to menu governor. It should not increase later once system is fully up? Do you see it increasing later?

Quoted 12 lines
Quoted 2 lines

I agree with the 'power' number. I did not like that

4294967295 there.

Quoted 3 lines

But, I had to put some number higher than other C-states, maximum possible seemed logical. May be I can change the sysfs interface to print <NULL> or something like that for power?

I dunno. Somehow I like 0 to signify an unknown quantity rather than a huge number. If somebody actually looks at it with a program, they're going to have to special case either of them, and 0 seems simpler.

Yes. But, if we have a 0W Cn state in future? :-).

Thanks,
Venki

reviewer
#6 lore raw
Quoted 17 lines · Venkatesh
Quoted 17 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Thursday, February 14, 2008 12:41 PM
To: Pallipadi, Venkatesh
Cc: [email protected]
Subject: Re: [PATCH] ACPI, CPU_IDLE: Add more information about C-states

Quoted 6 lines · Venkatesh

'usage' is a counter that counts every time we get into poll_idle routine. I also try to keep track of time spent in poll_idle, until need_resched sends us out. That time is accumulated in 'time'. Just have those to be consistent with other state and to be sure that powertop kind of tools wont get confused.

Quoted 6 lines
Quoted 2 lines

yes, the consistency is good.
But my question is when and why we enter poll_idle at all.

Ohh. Ok. May be the ladder governor used it for a while, before we switch to menu governor. It should not increase later once system is fully up? Do you see it increasing later?

i haven't noticed it increase, but will look.

Quoted 7 lines
Quoted 7 lines
Quoted 2 lines

I agree with the 'power' number. I did not like that

4294967295 there.

Quoted 3 lines

But, I had to put some number higher than other C-states, maximum possible seemed logical. May be I can change the sysfs interface to print <NULL> or something like that for power?

Quoted 7 lines
Quoted 5 lines

I dunno. Somehow I like 0 to signify an unknown quantity rather than a huge number. If somebody actually looks at it with a program, they're going to have to special case either of them, and 0 seems simpler.

Yes. But, if we have a 0W Cn state in future? :-).

actually, the entire field is really worthless. we all know that BIOS writers just take the example code and use it multiple systems w/o changing these values. Perhaps we should re-cosider exposing this field, as it is mis-leading, at best...

-len