Re: [RFC] why do sensors break CPU scaling

[Tom Psyborg <pozega.tomislav@gmail.com>]

On 21/11/2019, David Niklas <Hgntkwis@vfemail.net> wrote:
> On Wed, 20 Nov 2019 21:42:12 +0100
> Tom Psyborg <pozega.tomislav@gmail.com> wrote:
>> Hi
>>
>> Recently I've needed to set lowest CPU scaling profile, running ubuntu
>> 16.04.06 I used standard approach - echoing powersave to
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor.
>> This did not work as the
>> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq kept returning
>> max scaling freq.
>>
>> During testing of ubuntu 19.10 I've found that the above approach
>> actually does work, but as long as there are no xsensors (or just
>> sensors from cli) being run.
>> cpuinfo_cur_freq in this case was returning variable values +- 1% of
>> around 1.4GHz.
>> As soon as I issue sensors command cpuinfo_cur_freq jumps to 3.5GHz
>> for a fraction of second and returns back to 1.4GHz afterwards. If
>> running xsensors it keeps bouncing between 1.4 and 3.5GHz all the
>> time.
>>
>> Rebooted back to 16.04.6 and was able to set lowest CPU scaling freq
>> as well, but issuing sensors command here once just breaks CPU scaling
>> that now remains at about 3.5GHz.
>> It can be set to lowest scaling freq again without rebooting but it
>> needs to change scaling_governor for all cores to something else and
>> then back to powersave.
>>
>> Why is this happening, shouldn't sensors command just read temp/fan
>> values without writing to any of the CPU control registers?
>
> I don't know if the maintainers will notice your email, but I did. I
> don't guarantee that they'll notice or help you, but this should assist
> you in writing a proper question.
> You need to include the output of uname -a on both ubuntu boxes. The
> output of:
> dpkg -l xsensors
> dpkg -l lm-sensors

this is on 16.04.6

whtw46ww4@I5576:~$ uname -a
Linux I5576 4.15.0-51-generic #55~16.04.1-Ubuntu SMP Thu May 16
09:24:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
whtw46ww4@I5576:~$ dpkg -l xsensors
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                          Version
       Architecture                Description
+++-=============================================-===========================-===========================-===============================================================================================
ii  xsensors                                      0.70-3
       amd64                       hardware health information viewer
whtw46ww4@I5576:~$ dpkg -l lm-sensors
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                          Version
       Architecture                Description
+++-=============================================-===========================-===========================-===============================================================================================
ii  lm-sensors                                    1:3.4.0-2
       amd64                       utilities to read
temperature/voltage/fan sensors


>
> The information on which processor you own and the motherboard and
> it's BIOS version just in case.
>
> This is just my understanding and it might be wrong, but the CPU is
> probably accessed to do the request to the fan values and so it ramps up
> expecting to have to deal with a more intense workload (which is exactly
> what Ryzen and several newer Intel processors are supposed to do), and so
> you're seeing expected behavior.

I don't think that is the case here, since I can run any kind of more
demanding app than xsensors is, even compile software with -j 5
(multithread) and CPU clocks don't exceed 1.40GHz. Only on xsensors
launch CPU clocks are reset.

Regards, Tom