I was going through the Linux power management files, and I am confused about the C and S states.

  • The C-states are defined in /sys/devices/system/cpux/cpuidle/. From what I understand they are used to put the CPU in different sleep states depending on the level of idleness.
  • The S-state interface is in /sys/power/state and I can see different sleep states like freeze, standby, mem, etc. If I read their description they are trying to accomplish the same thing that the C-states are trying to do.

This brings me to my question: What is the difference between them? And if I want to prevent my system from going into idle, what parameters should I set. I set the disable parameter for the C-state in /sys/devices/system/cpux/cpuidle/ but I could still observe my phone going into the idle state (used systrace for observation).

2 Answers 2


S-states are global ACPI states: they describe the power state of the entire system. State changes of this type are generally user-requested or at least user-configurable (e.g. timeouts, standby on low battery etc.).

C-states are processor states: they describe the power state of an individual CPU package (or even core). State changes of this type are generally automatic, and don’t affect the overall state of the system: the CPU can go to sleep and wake back up without involving the rest of the system.

I’m not sure disabling C-state transitions is all that useful in most cases (especially on a phone); you’re probably after disabling S-state transitions. The “idle” state is implemented in software and not an official ACPI state, so you won’t find hardware control over that. S-state transitions are software-controlled, so for example on a systemd-controlled system, you’d disable sleep there; I don’t know how to disable sleep states on phones.

  • Why would disabling C-state transitions not be useful? Nov 6, 2019 at 17:58
  • C-state transitions are supposed to be transparent, and for many workloads they are... I don’t know for your specific case, so perhaps it is useful for you. You’d have to explain what you’re trying to achieve in more detail ;-). Nov 6, 2019 at 18:14
  • I am trying to see if I can disable my CPU cores from going into any of the C states. In this doc (kernel.org/doc/html/v5.0/admin-guide/pm/cpuidle.html), it says that I can disable a given idle state by setting the 'disable' attribute for that particular state in a specific core. I did that, and I can still see my cores going into the idle state (I used systrace for observing that). So, I am not sure if there is any other power management system (apart from CPU Idle) which is driving the cores to these C states. Nov 6, 2019 at 18:33
  • Another way to frame my question would be, are there any other power management systems which can override the decisions made by CPUIdle which decides the C-states? Nov 6, 2019 at 18:35

If you have freeze, standby etc. these are almost manual commands. What laptops (can) connect to the closing of the lid, which in the end is also a voluntary act.

echo mem > /sys/power/state

Is how I put my system (mini-pc, no lid) to S3 in an instant. Watt goes from 3.5 to 1.2. (poweroff still has 0.7W) With the default xorg timeout soft sleep it is 2.5W. This must be S1 or S2.

]# cat /sys/power/mem_sleep 
s2idle [deep]

This is for controlling what kind of sleep you want.

But the distro/kernel has to support your hardware, and that is not so easy. I soon stopped playing around, once I had my "echo mem" on my distro. (I don't know about phones). I even chose that distro because things like that worked so well.

S-states, if supported, are like user commands, not just things that happen with time or low energy.

C-states are a mostly CPU-internal thing for G0 "Working" state. A multicore CPU carefully puts some cores to some C state, so it can be reactivated in no time. The definitions in the Wiki link are a bit tentative. See the "C10" hint, this is not a Haswell speciality. This is how "modern" CPUs combine low energy and high performance.

"suspend-to-ram" is a good example: CPU shall sleep, very deep, and the system is quite shut off except for a special minimal RAM keepalive state. If the CPU takes a split second to come back, no problem.

But if one or more cores go to some sleep state automatic because of low system load (idle, but running system), they have to be reactivated very fast.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.