Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

mrlamud · 2017-09-26 01:34:34

Normal idle frequency is about 800Mhz but it’s never dropped below 1Ghz since upgrade to kernel 4.13.
The kernel option intel_pstate=disable solved this problem but also disable turbo speed.

Mod Edit: please don't use [closed] in titles; it makes the thread look like it has been administratively closed, which this has not.

Last edited by fukawi2 (2017-09-27 04:18:10)

loqs · 2017-09-26 02:41:08

Does linux 4.13.3-1 also show the higher idle frequency?

mrlamud · 2017-09-26 03:01:36

loqs wrote:

Does linux 4.13.3-1 also show the higher idle frequency?

It does.

loqs · 2017-09-27 00:56:42

Would suggest building 4.13.3. locally with the .config from 4.12.y to check if it is a none default config change.
If it is not the result of a .config change bisecting between 4.12 and 4.13 should locate the commit responsible.

mrlamud · 2017-09-27 01:48:24

loqs wrote:

Would suggest building 4.13.3. locally with the .config from 4.12.y to check if it is a none default config change.
If it is not the result of a .config change bisecting between 4.12 and 4.13 should locate the commit responsible.

Thanks for the advice.
It might be a touch of Intel P-state driver for function improvement in kernel 4.13 which effects Intel Haswell-refresh.
I hope someone which has more caliber than me find it and file a bug to kernel.org.

graysky · 2017-09-27 08:55:19

You probably want to sample the frequency over a period of time to verify that it is in fact different. Observations without data are more perception that reality. I will post a script to help you later today.

mrlamud · 2017-09-27 09:01:51

graysky wrote:

You probably want to sample the frequency over a period of time to verify that it is in fact different. Observations without data are more perception that reality. I will post a script to help you later today.

Many thanks grasky.

graysky · 2017-09-27 18:48:23

graysky wrote:

You probably want to sample the frequency over a period of time to verify that it is in fact different. Observations without data are more perception that reality. I will post a script to help you later today.

https://github.com/graysky2/bin/blob/ma … stogram.sh

Example on my i4790K under 4.13.3-1 collecting data on xfce4 for 75 seconds:

% cpufreq_histogram.sh 75 
Collecting data for 75 seconds...
# NumSamples = 75; Min = 800.00; Max = 4400.10
# Mean = 1074.234667; Variance = 276643.987598; SD = 525.969569; Median 900.200000
# each ∎ represents a count of 1
  800.0000 -  1160.0100 [    57]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (76.00%)
 1160.0100 -  1520.0200 [    13]: ∎∎∎∎∎∎∎∎∎∎∎∎∎ (17.33%)
 1520.0200 -  1880.0300 [     0]:  (0.00%)
 1880.0300 -  2240.0400 [     2]: ∎∎ (2.67%)
 2240.0400 -  2600.0500 [     1]: ∎ (1.33%)
 2600.0500 -  2960.0600 [     1]: ∎ (1.33%)
 2960.0600 -  3320.0700 [     0]:  (0.00%)
 3320.0700 -  3680.0800 [     0]:  (0.00%)
 3680.0800 -  4040.0900 [     0]:  (0.00%)
 4040.0900 -  4400.1000 [     1]: ∎ (1.33%)

note the log file is /run/user/1000/stats-20170927-144610

mrlamud · 2017-09-27 23:54:53

Cpufreq_histograms collected from the same environment - gnome-wayland.

Linux-4.13.4-1-zen [testing]

Collecting data for 75 seconds...
# NumSamples = 75; Min = 1106.50; Max = 3643.50
# Mean = 2492.529333; Variance = 499500.255940; SD = 706.753320; Median 2549.300000
# each ∎ represents a count of 1
 1106.5000 -  1360.2000 [     2]: ∎∎ (2.67%)
 1360.2000 -  1613.9000 [     8]: ∎∎∎∎∎∎∎∎ (10.67%)
 1613.9000 -  1867.6000 [    11]: ∎∎∎∎∎∎∎∎∎∎∎ (14.67%)
 1867.6000 -  2121.3000 [     5]: ∎∎∎∎∎ (6.67%)
 2121.3000 -  2375.0000 [     6]: ∎∎∎∎∎∎ (8.00%)
 2375.0000 -  2628.7000 [    10]: ∎∎∎∎∎∎∎∎∎∎ (13.33%)
 2628.7000 -  2882.4000 [     5]: ∎∎∎∎∎ (6.67%)
 2882.4000 -  3136.1000 [    11]: ∎∎∎∎∎∎∎∎∎∎∎ (14.67%)
 3136.1000 -  3389.8000 [     8]: ∎∎∎∎∎∎∎∎ (10.67%)
 3389.8000 -  3643.5000 [     9]: ∎∎∎∎∎∎∎∎∎ (12.00%)

note the log file is /tmp/stats-20170928-123102

Linux-4.13.3-1-zen

Collecting data for 75 seconds...
# NumSamples = 75; Min = 1425.50; Max = 3595.20
# Mean = 2533.793333; Variance = 479643.319556; SD = 692.562863; Median 2352.400000
# each ∎ represents a count of 1
 1425.5000 -  1642.4700 [     6]: ∎∎∎∎∎∎ (8.00%)
 1642.4700 -  1859.4400 [    11]: ∎∎∎∎∎∎∎∎∎∎∎ (14.67%)
 1859.4400 -  2076.4100 [    13]: ∎∎∎∎∎∎∎∎∎∎∎∎∎ (17.33%)
 2076.4100 -  2293.3800 [     4]: ∎∎∎∎ (5.33%)
 2293.3800 -  2510.3500 [     4]: ∎∎∎∎ (5.33%)
 2510.3500 -  2727.3200 [     4]: ∎∎∎∎ (5.33%)
 2727.3200 -  2944.2900 [     4]: ∎∎∎∎ (5.33%)
 2944.2900 -  3161.2600 [     6]: ∎∎∎∎∎∎ (8.00%)
 3161.2600 -  3378.2300 [    14]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (18.67%)
 3378.2300 -  3595.2000 [     9]: ∎∎∎∎∎∎∎∎∎ (12.00%)

note the log file is /tmp/stats-20170928-064120

Linux 14.12.13-1 (stock archlinux)

Collecting data for 75 seconds...
# NumSamples = 75; Min = 799.80; Max = 3695.10
# Mean = 1489.466667; Variance = 807109.914489; SD = 898.392962; Median 1000.000000
# each ∎ represents a count of 1
  799.8000 -  1089.3300 [    40]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (53.33%)
 1089.3300 -  1378.8600 [     9]: ∎∎∎∎∎∎∎∎∎ (12.00%)
 1378.8600 -  1668.3900 [     2]: ∎∎ (2.67%)
 1668.3900 -  1957.9200 [     6]: ∎∎∎∎∎∎ (8.00%)
 1957.9200 -  2247.4500 [     6]: ∎∎∎∎∎∎ (8.00%)
 2247.4500 -  2536.9800 [     1]: ∎ (1.33%)
 2536.9800 -  2826.5100 [     1]: ∎ (1.33%)
 2826.5100 -  3116.0400 [     1]: ∎ (1.33%)
 3116.0400 -  3405.5700 [     3]: ∎∎∎ (4.00%)
 3405.5700 -  3695.1000 [     6]: ∎∎∎∎∎∎ (8.00%)

note the log file is /tmp/stats-20170928-064741

Last edited by mrlamud (2017-09-28 05:37:19)

gnox · 2017-09-29 02:26:18

Hi, I noticed the same in a Laptop with Haswell processor i7-4710HQ, when I use linux-zen 4.13 or linux 4.13, the value "cpu Mhz" in /proc/cpuinfo shows always the maximun value, but when using linux-ck 4.12 "cpu Mhz" shows different values.

Looking into the script of graysky, the values of what the script parse "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" it varies correctly, in any linux-zen 4.13, linux 4.13, linux-ck 4.12, so maybe is only /proc/cpuinfo that is not showing the correct value but the processors are indeed working as expected.

Found this : https://www.heise.de/newsticker/meldung … 04813.html

The Linux 4.13, expected in September, can scramble structures in the binary code to make it more difficult for attackers to penetrate. The / proc / cpuinfo file no longer reveals the current clock rate of the processor.
...
In addition to improvements to security, 4.13 also includes a number of innovations in the infrastructure code. Through some of them, / proc / cpuinfo no longer shows the current clock frequency on x86 systems, but the basic clock of the processor.

Some monitor programs have to change the source of the cpu freq information .

Last edited by gnox (2017-09-29 02:33:16)

mrlamud · 2017-09-30 02:10:45

I found an interesting good point of Kernel 4.13. It's much better than LTS kernel under some working loads like watching HTML5 media.

Linux-lts 4.9.52

Collecting data for 75 seconds...
# NumSamples = 75; Min = 3396.60; Max = 3693.50
# Mean = 3620.024000; Variance = 3469.864224; SD = 58.905553; Median 3627.000000
# each ∎ represents a count of 1
 3396.6000 -  3426.2900 [     1]: ∎ (1.33%)
 3426.2900 -  3455.9800 [     0]:  (0.00%)
 3455.9800 -  3485.6700 [     2]: ∎∎ (2.67%)
 3485.6700 -  3515.3600 [     1]: ∎ (1.33%)
 3515.3600 -  3545.0500 [     3]: ∎∎∎ (4.00%)
 3545.0500 -  3574.7400 [     9]: ∎∎∎∎∎∎∎∎∎ (12.00%)
 3574.7400 -  3604.4300 [     7]: ∎∎∎∎∎∎∎ (9.33%)
 3604.4300 -  3634.1200 [    17]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (22.67%)
 3634.1200 -  3663.8100 [    12]: ∎∎∎∎∎∎∎∎∎∎∎∎ (16.00%)
 3663.8100 -  3693.5000 [    23]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (30.67%)

note the log file is /tmp/stats-20170930-085447

Linux 4.13.3-zen

Collecting data for 75 seconds...
# NumSamples = 75; Min = 1506.10; Max = 2630.50
# Mean = 1883.853333; Variance = 49358.749422; SD = 222.168291; Median 1857.400000
# each ∎ represents a count of 1
 1506.1000 -  1618.5400 [     6]: ∎∎∎∎∎∎ (8.00%)
 1618.5400 -  1730.9800 [    12]: ∎∎∎∎∎∎∎∎∎∎∎∎ (16.00%)
 1730.9800 -  1843.4200 [    19]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (25.33%)
 1843.4200 -  1955.8600 [    18]: ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ (24.00%)
 1955.8600 -  2068.3000 [     6]: ∎∎∎∎∎∎ (8.00%)
 2068.3000 -  2180.7400 [     5]: ∎∎∎∎∎ (6.67%)
 2180.7400 -  2293.1800 [     4]: ∎∎∎∎ (5.33%)
 2293.1800 -  2405.6200 [     4]: ∎∎∎∎ (5.33%)
 2405.6200 -  2518.0600 [     0]:  (0.00%)
 2518.0600 -  2630.5000 [     1]: ∎ (1.33%)

note the log file is /tmp/stats-20170930-085136

graysky · 2017-09-30 10:20:28

gnox wrote:

...
Looking into the script of graysky, the values of what the script parse "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" it varies correctly, in any linux-zen 4.13, linux 4.13, linux-ck 4.12, so maybe is only /proc/cpuinfo that is not showing the correct value but the processors are indeed working as expected.
Found this : https://www.heise.de/newsticker/meldung … 04813.html
The Linux 4.13, expected in September, can scramble structures in the binary code to make it more difficult for attackers to penetrate. The / proc / cpuinfo file no longer reveals the current clock rate of the processor.
...
In addition to improvements to security, 4.13 also includes a number of innovations in the infrastructure code. Through some of them, / proc / cpuinfo no longer shows the current clock frequency on x86 systems, but the basic clock of the processor.
Some monitor programs have to change the source of the cpu freq information .

Yes, and as you say, my script hits /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq which is an accurate reflection of true cpufreq as far as I can tell.

Arch Linux

#1 2017-09-26 01:34:34

Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#2 2017-09-26 02:41:08

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#3 2017-09-26 03:01:36

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#4 2017-09-27 00:56:42

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#5 2017-09-27 01:48:24

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#6 2017-09-27 08:55:19

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#7 2017-09-27 09:01:51

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#8 2017-09-27 18:48:23

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#9 2017-09-27 23:54:53

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#10 2017-09-29 02:26:18

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#11 2017-09-30 02:10:45

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

#12 2017-09-30 10:20:28

Re: Linux-zen 4.13.3-1 , Haswell Refresh’s high idle frequency.

Board footer