Merge ~joalif/ubuntu/+source/systemd:lp1806012 into ubuntu/+source/systemd:ubuntu/eoan-devel

I do not agree with the rationale for this change. /etc/default files are not a particularly good interface overall, and the use cases presented are all addressed by disabling the systemd unit completely instead of supporting selection of different governors via this unit.

I should say that respecting the setting for cpufrequtils is sensible, but I think this should be accomplished by making this unit a no-op in the presence of that file, not having ondemand reapply the same policy.

> I should say that respecting the setting for cpufrequtils is sensible

cpufrequtils has not seen updates since trusty:

$ rmadison cpufrequtils
 cpufrequtils | 007-2 | precise/universe | source, amd64, armel, armhf, i386, powerpc
 cpufrequtils | 008-1 | trusty/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el
 cpufrequtils | 008-1 | xenial/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
 cpufrequtils | 008-1build1 | bionic/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
 cpufrequtils | 008-1build1 | cosmic/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
 cpufrequtils | 008-1.1 | disco/universe | source, amd64, arm64, armhf, i386, s390x
 cpufrequtils | 008-1.1 | eoan/universe | source, amd64, arm64, armhf, i386, s390x

additionally, refusing to make 'ondemand' configurable means anyone wanting to configure their system has to both install cpufrequtils (which is unsupported for UA customers, since it's universe) as well as disabling 'ondemand'.

Seeing the future, it's quite possible that debian (and/or us) simply drop cpufrequtils at some point.

> /etc/default files are not a particularly good interface overall

however, they are widely used for configuration in debian and ubuntu.

> use cases presented are all addressed by disabling the systemd unit

not without *also* installing the cpufrequtils package. Simply disabling ondemand will leave the governor at the kernel-compiled default.

> but I
> think this should be accomplished by making this unit a no-op in the presence
> of that file, not having ondemand reapply the same policy.

option 1) change cpu-setfreq to be a noop when /etc/default/cpufrequtils is detected, AND install cpufrequtils
option 2) change cpu-setfreq to honor /etc/default/cpufrequtils selection, with *or* without cpufrequtils installed

the end result is the same; the only difference is your design requires cpufrequtils to be installed. Is there a reason that design is better than this merge proposal?

and of course:

option 3) change cpu-setfreq to be a noop when /etc/default/cpufrequtils is detected, but without cpufrequtils installed -> this leads to the governor being completely unset, defaulting to the kernel compile default. Probably not exactly expected.

/etc/default/cpufrequtils is a conffile of the cpufrequtils package; I think it is reasonable to respect it if present but that this should be implemented by delegating to the cpufrequtils package in this case.

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?

> additionally, refusing to make 'ondemand' configurable means anyone wanting to configure their system has to both install cpufrequtils (which is unsupported for UA customers, since it's universe) as well as disabling 'ondemand'.

Another option would be to disable ondemand and add a systemd service unit to do what you want instead. For user-known hardware, it'd be pretty much a one-liner, right? Is there any reason this wouldn't be viable?

I had a quick look at what other distributions are currently doing.

From what I can see it seems that Fedora and Arch are currently using the 'cpupower' tool (from linux-tools-common on Ubuntu, kernel-tools on Fedora) and then have a systemd service which relatively simply kicks off a call to 'sudo cpupower -c all frequency-set -g powersave' or similar. That systemd service isn't upstream in the kernel though.

RHEL seems to primarily use tuned to drive the change, which has it's own script to manually twiddle the /sys/devices/system/cpu/*/cpufreq/scaling_governor files.

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.