Values in sub-windows are not refreshed

[Betaminos]

Hello there,

thank you for this great program! :)
I have come across another minor bug that I would like to point out.

When opening sub-windows, e.g. Technologies, CoreFreq will show the values:

The values as they are shown are partially stored as a value of 4005e in MSR 0x1FC:

sudo rdmsr 0x1fc
4005e

Switching the values like so (as an example), i.e. the lower 3 ONs are now OFFs:

causes the MSR to change to 1c005e:

sudo rdmsr 0x1fc
1c005e

The bug happens, when I manually set the MSR 0x1FC back to 4005e:

sudo wrmsr 0x1fc 0x4005e

The values take effect / are written correctly, as can be seen via:

sudo rdmsr 0x1fc
4005e

The bug, in my opinion, is that CoreFreq still shows:

(I understand that reading the various MSRs once per second, or whatever refresh interval is set, would cause issues.)
This display does not change, however, even when the Technologies window is closed and opened back up.
I am only able to get CoreFreq to refresh the values, when I change one value stored inside the same MSR.
For example, changing Turbo Boost back to ON causes the refresh only for fields where the value is stored in the same MSR as Turbo Boost.
As the other two values (R2H and EEO) are not stored in this MSR, they continue being shown as OFF despite being ON.
Changing either of them via CoreFreq causes the MSR to be read and will update the other values.

My proposal is to refresh / read all the values of MSRs contained in a window, each time the window is opened.
A full refresh while the window is open seems excessive to me, but having an up to date status of the values when re-opening the window would be great.

Thank you for your time and consideration.

PS: I have started messing about with the MSRs as I would like to have some settings applied on boot and have not found a way for CoreFreq to do so.
Due to this, I am changing the MSRs via a script on boot and have tried to check them via CoreFreq when I came across this bug.

[cyring]

You are right that bits within CoreFreq are not updated when registers are externally altered.

EDIT: Exception of /sys/ variables which are tracked by driver.
For example /sys/devices/system/cpu/cpufreq/boost

This was an implementation choice in favor of less CoreFreq CPU overhead.
The main purpose of CoreFreq is CPU monitoring and I'm chasing any wasted cycle.

CoreFreq UI is an all in one tool where you are supposed to tweak bits straight from it, and not externally (wrmsr, setpci, and so on).

Meanwhile, a special shortcut exists to request a full refresh: press the star key *

However if some indicators like EEO, R2H, despite a refresh request, are not reflected then I'll debug those cases.

[cyring]

• EEO and R2H use case

Nominal is ON

After disabling both

Re-enabling


Final state

• Probably those features are missing or not implemented for your processor ?
  Please post the output of corefreq-cli -s -n -k

[cyring]

• FYI, EEO and R2H are set in MSR_IA32_POWER_CTL

CoreFreq/corefreqk.c

Line 3331 in 20426b6

WRMSR(PowerCtrl, MSR_IA32_POWER_CTL);

CoreFreq/intelmsr.h

Line 86 in 20426b6

#define MSR_IA32_POWER_CTL 0x000001fc

[Betaminos]

• Probably those features are missing or not implemented for your processor ?

Changing them via the software works just fine and the status is reflected correctly.
I tried to describe how to get to the specific issue I am facing, by manually changing the MSRs outside of CoreFreq and then using CoreFreq to check on them.

This was an implementation choice in favor of less CoreFreq CPU overhead. The main purpose of CoreFreq is CPU monitoring and I'm chasing any wasted cycle.

CoreFreq UI is an all in one tool where you are supposed to tweak bits straight from it, and not externally (wrmsr, setpci, and so on).

I see.
My scenario is the external change of MSRs, e.g. through a script or embedded controller, unknown to the user.
Due to this, I would have preferred if opening a window causes a refresh of all values contained in that window.
After all, if a user is actively switching windows inside CoreFreq, then CoreFreq is not running idly in the background.
Due to this, I would be fine with it using a few more CPU cycles when opening a window, if these CPU cycles go towards refreshing the content.

Meanwhile, a special shortcut exists to request a full refresh: press the star key *

The star key does not seem to do anything on my keyboard, but your description sounds exactly like the thing I am expecting opening a window to do.

[cyring]

Are these issues still with your processor i7-1165G7 of Alder Lake architecture ?

If not, please post the output of corefreq-cli -s -n -k

[cyring]

I see. My scenario is the external change of MSRs, e.g. through a script or embedded controller, unknown to the user. Due to this, I would have preferred if opening a window causes a refresh of all values contained in that window. After all, if a user is actively switching windows inside CoreFreq, then CoreFreq is not running idly in the background. Due to this, I would be fine with it using a few more CPU cycles when opening a window, if these CPU cycles go towards refreshing the content.

In fact CoreFreq model is not a pull model but a push model.

List of registers are collected by driver. CLI has no control over the chosen list of MSRs, CSRs, and other low level means.

Which means that Driver is continually collecting whatever the state of Deamon, CLI and/or GUI.
In short, it's a broadcast model

What I understand from your needs seems a code refactoring to me. But I tends to stabilize CoreFreq: bug fix only.