Open braun-steven opened 6 months ago
Hello,
thanks for the detailed investigation.
I had a look and there does seem to be missing the case where behaviour for the scaling driver amd-pstate-epp
should be handled like intel_pstate
. I will fix this but I don't think it will fix nor explain the behaviour that is causing your confusion.
Here's an attempt to explain what is happening.
The amd-pstate-epp
scaling driver is relatively new and behaves similarly to the intel_pstate
one in that
scaling_governor
s: powersave
and performance
energy_performance_preference
(epp) knobHowever, in this mode the scaling_min_freq
and scaling_max_freq
(even though writable) do not have any effect. Turns out you can change a status knob to "passive" to switch out of this mode. Therefore current logic in TCC is if min/max freq is used to restrict frequencies the status will be set to "passive", otherwise remain in active mode.
The consequence of the "passive" mode which allows the change is that the scaling_driver
is set to amd-pstate
instead. With this the governors are replaced by the traditional acpi-cpufreq governors. In this state the TCC logic chooses one known available governor where cpu frequency limitation is known possible (first choice ondemand
).
Further, the epp knob for the amd-pstate-epp scaling driver does list a possible "default" value option (which TCC writes to enforce a default value). Writing to it, however, yields an error. This, as far as I can see, is a bug in the driver.
Coming back to the topic
TCC does not set scaling governor and energy performance preference correctly
what would be correct?
Thanks for the response!
I had a look and there does seem to be missing the case where behaviour for the scaling driver amd-pstate-epp should be handled like intel_pstate.
Exactly, I just only read up on amd_pstate_epp
yesterday evening and thought that this might be missing in TCC.
TCC does not set scaling governor and energy performance preference correctly
what would be correct?
I understand, that it is not simple, but from a user perspective, I would enjoy having the following two ways of setting up a TCC profile (the "System Performance" part at least):
amd_pstate_epp
), number of logical coresThe issue I see with how it is implemented right now is that there are conflicting options. E.g. one can choose "System Profile: Low-power" but set "Maximum performance" to True (I guess this chooses performance
as governor?). It is not really clear what "System Profile" (even after reading the short description on mouse hover) sets. Also, looking at the predefined TCC profiles, all of them set the "System Profile" to "Performance" -- this probably adds to the confusion.
But maybe this also goes against your ideas of how the TCC should work and which low-level options it should expose to the user or how abstract the concepts should be. Anyway, I'm glad that I could help identifying the missing amd_pstate_epp
case :-)
Hey there,
I observed some unexpected behavior of how TCC sets CPU scaling governor and energy performance profiles.
System Info
CPU Governor and EPP:
Both obtained via
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
and/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference
powersave
balance_performance
powersave
balance_performance
ondemand
No such file or directory
ondemand
No such file or directory
Logs:
Obtained with
journalctl -u tccd -f
:TUXEDO Defaults:
Default:
Cool and breezy:
Powersave extreme:
Investigating the TUXEDO Defaults profile
Let's look at the "TUXEDO Defaults" profile. The default governor is specified here:
https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/common/models/DefaultProfiles.ts#L213
but apparently this variable is unused and we need to check the logic in
CpuWorker.ts->applyCpuProfile(...)
over at https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L134Further down this method, we can find https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L156-L161
which first finds the "default" governor.
This is done by checking the scaling driver at
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L65-L71Mine is:
It then checks the special case
intel_pstate
and if its notintel_pstate
it continues to find thescalingAvailableGovernors
(/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
) and selects the first governor inCpuWorker.preferredAcpiFreqGovernors
(one of[ 'ondemand', 'schedutil', 'conservative' ]
)https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L73-L87
Preferred acpi freq governors in
CpuWorker
:https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L30
On my system, the available scaling governors are
So this matches none of the
CpuWorker.preferredAcpiFreqGovernors
which makesCpuWorker.findDefaultGovernor()
returnchosenName = undefined
at https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L80-L87Then the profile will have an
undefined
governor https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L158-L160which calls
CpuController.setGovernor(governor)
and does nothing since it isundefined
:https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/common/classes/CpuController.ts#L207-L210
Since
applyCpuProfile
callssetCpuDefaultConfig
before applying any settings, this should then end up with the defaults: https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L138But
setCpuDefaultConfig
itself callsthis.findDefaultGovernor
which again returnsundefined
: https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L194Suggestions
Logic needs to be implemented for the case that
findDefaultGovernor
does not match any of the defined governors here https://github.com/tuxedocomputers/tuxedo-control-center/blob/3006a3a4df7baeeb5a9abe817a94358ae2f903eb/src/service-app/classes/CpuWorker.ts#L30C22-L30C48I'm also surprised, that none of them is
performance
?I'm not sure what happened with
energy_performance_preference
in the case of theCool and breezy
profile: apparently the file is deleted? The profile is defined in a file calledLegacyProfiles.ts
and I didn't want to start investigating what happens with something that you already deem asLegacy
.Anyway, I'm switching away from TCC to auto-cpufreq or tlp until this is fixed. I hope I could help. Let me know if you need any further information from my system or how TCC behaves on my system.