Code review comment for ~joalif/ubuntu/+source/systemd:lp1806012

Revision history for this message
Ioanna Alifieraki (joalif) wrote :

The kernel default governor is performance.
The 'ondemand' service will choose first interactive, then ondemand and finally
powersave.
(I use 'ondemand' to refer to the systemd service and differentiate it from
ondemand governor.)

Of course depending on the cpufreq driver in use there may be more governors
available such as conservative, userspace and schedutils.

The governor that will be selected depends on :
1) The processor (Intel, ARM etc.)
2) The BIOS settings (OS control, Dynamic etc.)
3) The cpufreq driver used (intel_pstate, pcc-cpufreq, acpi-cpufreq)
4) The available cpufreq governors and the behaviour of 'ondemand' service.

1 and 2 will define the cpufreq driver that will be used (3).
Based on the driver there will be some available governors and 'ondemand' service
will select one of them.

'Ondemand' behaviour or the kernel default suffice when we assume an intel
processor, with intel_pstate driver enabled.
In this case we have available only 2 governors : powersave and performance.
If 'ondemand' is enabled the powersave will be selected, if disabled the kernel
defaults to performance.
(Please note that the powersave and performance governors of intel_pstate are
very different from the acpi-cpufreq ones.)

If we don't run on an intel processor (e.g. ARM) or even if we run on intel
with intel_pstate disabled, then with 'ondemand' enabled the selected governor
will be ondemand and when disabled will be performance.
However, in that case you have more options (powersave, userspace, conservative,
scheduitls).
The current behaviour of 'ondemand' service does not allow you to use any other
governor.

> Is there an actual requirement from a user for setting the governor to a value
that is neither the kernel default nor the ondemand behavior?

I have a laptop with an ARM based CPU.
I want powersave governor because I am low on battery.
Neither enabling nor disabling 'ondemand' service will do the job.

To sum up, currently 'ondemand' is working fine for the average case (intel CPU+intel_pstate driver).
However, this is not the only case.
Modifying 'ondemand' service to make the right decision for every possible
combination of 1,2,3 is way too complicated and maybe impossible given that different
users have different demands for performance and power saving (this is after all the rational behind having all these governors).

This MP does NOT change the default behaviour of 'ondemand'.
It just provides more options for the users.
Plus it resolves the compatibility issues with cpufrequtils.
I can see benefits here and no harm.
And, yes, there are other workarounds (disabling 'ondemand', adding one more service
to do what the user wants etc.).
However I don't see why this is simpler than having 'ondemand' service configurable.

« Back to merge proposal