Skip to contentSkip to conversation

cpuidle: sysfs: Display idle state enter function name

PATCH In review Aaron Tomlin 2 participants 6 messages Nov 19, 2025 – Nov 24, 2025 CPU idle time management framework

lore
Share & tools
lore
#0 lore raw

v2 cover cpuidle: sysfs: Display idle state enter function name

Changes since v1 [1]:

- Correct commit message

[1]: https://lore.kernel.org/lkml/[email protected]/

Aaron Tomlin (1):
cpuidle: sysfs: Display idle state enter function name

 Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
 drivers/cpuidle/sysfs.c                            | 9 +++++++++
 2 files changed, 16 insertions(+)
Signature · 1 line
2.51.0
#1 lore raw

PATCH v2 1/1 cpuidle: sysfs: Display idle state enter function name

This patch introduces a read-only "enter_function" attribute to the cpuidle sysfs interface. It exports the kernel symbolic name of the enter callback responsible for executing the CPU idle state entry state->enter(). It allows users to reliably map an abstract C-state e.g., "C0", to its concrete kernel implementation (e.g., poll_idle).

---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
 drivers/cpuidle/sysfs.c                            | 9 +++++++++
 2 files changed, 16 insertions(+)
Documentation/ABI/testing/sysfs-devices-system-cpu +7 -0
index 8aed6d94c4cd..7be4555d502a 100644
@@ -217,6 +217,13 @@ Description:
 		time (in microseconds) this cpu should spend in this idle state
 		to make the transition worth the effort.
 
+What:		/sys/devices/system/cpu/cpuX/cpuidle/state<N>/enter_function
+Date:		November 2025
+KernelVersion:	v6.18
+Contact:	Linux power management list <[email protected]>
+Description:
+		(RO) Display the symbolic name of the idle state's enter callback.
+
 What:		/sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/
 Date:		March 2018
 KernelVersion:	v4.17
drivers/cpuidle/sysfs.c +9 -0
index 61de64817604..dbd8d796ad29 100644
@@ -314,6 +314,13 @@ static ssize_t show_state_default_status(struct cpuidle_state *state,
 		       state->flags & CPUIDLE_FLAG_OFF ? "disabled" : "enabled");
 }
 
+static ssize_t show_state_enter_function(struct cpuidle_state *state,
+					 struct cpuidle_state_usage *state_usage,
+					 char *buf)
+{
+	return sysfs_emit(buf, "%ps\n", state->enter);
+}
+
 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);
@@ -326,6 +333,7 @@ define_one_state_rw(disable, show_state_disable, store_state_disable);
 define_one_state_ro(above, show_state_above);
 define_one_state_ro(below, show_state_below);
 define_one_state_ro(default_status, show_state_default_status);
+define_one_state_ro(enter_function, show_state_enter_function);
 
 static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_name.attr,
@@ -340,6 +348,7 @@ static struct attribute *cpuidle_state_default_attrs[] = {
 	&attr_above.attr,
 	&attr_below.attr,
 	&attr_default_status.attr,
+	&attr_enter_function.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(cpuidle_state_default);
Signature · 1 line
2.51.0
#2 lore raw
Quoted 8 lines · Aaron Tomlin

This patch introduces a read-only "enter_function" attribute to the cpuidle sysfs interface. It exports the kernel symbolic name of the enter callback responsible for executing the CPU idle state entry state->enter(). It allows users to reliably map an abstract C-state e.g., "C0", to its concrete kernel implementation (e.g., poll_idle).

I'm not really sure how this helps.

For example, the intel_idle driver uses the same function for all idle states except for the polling one, which is already advertised as polling.

Besides, why do you want users to look into the kernel source code to figure things out?

Quoted 61 lines
---
 Documentation/ABI/testing/sysfs-devices-system-cpu | 7 +++++++
 drivers/cpuidle/sysfs.c                            | 9 +++++++++
 2 files changed, 16 insertions(+)
Documentation/ABI/testing/sysfs-devices-system-cpu +7 -0
index 8aed6d94c4cd..7be4555d502a 100644
@@ -217,6 +217,13 @@ Description:
                time (in microseconds) this cpu should spend in this idle state
                to make the transition worth the effort.
 
+What:          /sys/devices/system/cpu/cpuX/cpuidle/state<N>/enter_function
+Date:          November 2025
+KernelVersion: v6.18
+Contact:       Linux power management list <[email protected]>
+Description:
+               (RO) Display the symbolic name of the idle state's enter callback.
+
 What:          /sys/devices/system/cpu/cpuX/cpuidle/state<N>/s2idle/
 Date:          March 2018
 KernelVersion: v4.17
drivers/cpuidle/sysfs.c +9 -1
index 61de64817604..dbd8d796ad29 100644
@@ -314,6 +314,13 @@ static ssize_t show_state_default_status(struct cpuidle_state *state,
                       state->flags & CPUIDLE_FLAG_OFF ? "disabled" : "enabled");
 }
 
+static ssize_t show_state_enter_function(struct cpuidle_state *state,
+                                        struct cpuidle_state_usage *state_usage,
+                                        char *buf)
+{
+       return sysfs_emit(buf, "%ps\n", state->enter);
+}
+
 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);
@@ -326,6 +333,7 @@ define_one_state_rw(disable, show_state_disable, store_state_disable);
 define_one_state_ro(above, show_state_above);
 define_one_state_ro(below, show_state_below);
 define_one_state_ro(default_status, show_state_default_status);
+define_one_state_ro(enter_function, show_state_enter_function);
 
 static struct attribute *cpuidle_state_default_attrs[] = {
        &attr_name.attr,
@@ -340,6 +348,7 @@ static struct attribute *cpuidle_state_default_attrs[] = {
        &attr_above.attr,
        &attr_below.attr,
        &attr_default_status.attr,
+       &attr_enter_function.attr,
        NULL
 };
 ATTRIBUTE_GROUPS(cpuidle_state_default);
--

2.51.0

#3 lore raw
Quoted 8 lines · Rafael J. Wysocki

I'm not really sure how this helps.

For example, the intel_idle driver uses the same function for all idle states except for the polling one, which is already advertised as polling.

Besides, why do you want users to look into the kernel source code to figure things out?

Hi Rafael,

While intel_idle uses a single function for most states today, other cpuidle drivers, different architectures, or future changes might implement per-state variations.

The mapping from abstract C-state names and descriptions (e.g., "C1", "C3") to the actual kernel implementation might not always be clear. Exposing the enter function offers a direct, cheap and reliable way to easily identify what is being executed for each state without using a kernel debugger (e.g., crash(8). Finally user-space tools might benefit from introspecting implementation details at runtime to validate configuration. This is primarily for the advanced user.

Please let me know if this clarifies the motivation.

Kind regards,

Signature · 1 line
Aaron Tomlin
#4 lore raw
Quoted 25 lines · Aaron Tomlin
Quoted 8 lines · Rafael J. Wysocki

I'm not really sure how this helps.

For example, the intel_idle driver uses the same function for all idle states except for the polling one, which is already advertised as polling.

Besides, why do you want users to look into the kernel source code to figure things out?

Hi Rafael,

While intel_idle uses a single function for most states today, other cpuidle drivers, different architectures, or future changes might implement per-state variations.

The mapping from abstract C-state names and descriptions (e.g., "C1", "C3") to the actual kernel implementation might not always be clear. Exposing the enter function offers a direct, cheap and reliable way to easily identify what is being executed for each state without using a kernel debugger (e.g., crash(8). Finally user-space tools might benefit from introspecting implementation details at runtime to validate configuration. This is primarily for the advanced user.

Quoted 1 line

Please let me know if this clarifies the motivation.

No, it doesn't. You'd need to tell me specifically what use case is going to be addressed by this change.

Though this is not going to fly regardless because exposing kernel internals via sysfs turns them into ABI which may hinder future improvements.

So let's first talk about what problem there is that needs addressing.

#5 lore raw
Quoted 8 lines · Rafael J. Wysocki

No, it doesn't. You'd need to tell me specifically what use case is going to be addressed by this change.

Though this is not going to fly regardless because exposing kernel internals via sysfs turns them into ABI which may hinder future improvements.

So let's first talk about what problem there is that needs addressing.

Hi Rafeal,

Apologies for the delay. I understand that turning internal details into an ABI can severely hinder future improvements, and I acknowledge that this is a critical barrier for the current approach. I do not currently have a more specific or compelling use case beyond this initial need.

Please ignore this patch.

Kind regards,

Signature · 1 line
Aaron Tomlin