The latter could be achieved much more easily without custom code, e.g. by using the cpuset cgroup controller to pin everything to CPU 0.
Which... Makes it hard for the user to notice the change? Cores will naturally go offline, but performance stays the same while you still use it.
I think this is just a demo of what you can do with user space scheduling and shouldn't be taken seriously...
All that `low_power` seems to do is prevent members from being kicked out of ‘idle’ while another in their group is ‘not idle’. This ‘idle’ state seems to be more of a guideline than the final decision, I believe if there is enough work to be done that it will get sent to ‘idle’ members.
The best analogy might be: three guys are dozing on the couch (the idle state), while the fourth guy is either doing chores (the active state) or else standing around generally being awake (the ready state). As long as the total amount of work doesn’t pile up past the awake guy’s capacity, he will let the others keep sleeping.
This is just saying, if something decided to idle the CPU, don't wake it just because there are tasks waiting to run (let something else decide to wake it).
E.g., if the system is overloaded for some period of time maybe it will wake a cpu in response to that, but a short burst in tasks won't result in waking up all the CPUs.