Public bug reported:
Ever since we upgraded from Ubuntu 18.04LTS to 22.04 LTS, we have been
noticing some issues with the CPU Frequency management on the system.
So, we did a side by side comparison and following are the details
### Machine Details
```bash
root@:~$
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 224
On-line CPU(s) list: 0-223
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Platinum 8176 CPU @ 2.10GHz
CPU family: 6
Model: 85
Thread(s) per core: 2
Core(s) per socket: 28
Socket(s): 4
Stepping: 4
CPU max MHz: 3800.0000
CPU min MHz: 1000.0000
BogoMIPS: 4200.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx
smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe
popcnt tsc_deadline_timer aes xsav
e avx f16c rdrand lahf_lm abm 3dnowprefetch
cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb
stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle
avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap
clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1
xsaves cqm_llc cqm_occup_llc cqm_mb
m_total cqm_mbm_local dtherm ida arat pln pts hwp
hwp_act_window hwp_epp hwp_pkg_req pku ospke md_clear flush_l1d
arch_capabilities
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 3.5 MiB (112 instances)
L1i: 3.5 MiB (112 instances)
L2: 112 MiB (112 instances)
L3: 154 MiB (4 instances)
NUMA:
NUMA node(s): 4
NUMA node0 CPU(s): 0-27,112-139
NUMA node1 CPU(s): 28-55,140-167
NUMA node2 CPU(s): 56-83,168-195
NUMA node3 CPU(s): 84-111,196-223
Vulnerabilities:
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache
flushes, SMT vulnerable
Mds: Mitigation; Clear CPU buffers; SMT vulnerable
Meltdown: Mitigation; PTI
Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Retbleed: Mitigation; IBRS
Spec store bypass: Mitigation; Speculative Store Bypass disabled via
prctl and seccomp
Spectre v1: Mitigation; usercopy/swapgs barriers and __user
pointer sanitization
Spectre v2: Mitigation; IBRS, IBPB conditional, RSB filling,
PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable
root@:~$
dmidecode -t system
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.2 present.
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Cisco Systems Inc
Product Name: DN2-HW-APL-XL
Version: A0
Serial Number: FCH2425L025
UUID: 8e99201b-e093-ff47-a881-c2f88d61b1e6
Wake-up Type: Other
SKU Number: Not Specified
Family: Not Specified
Handle 0x001D, DMI type 12, 5 bytes
System Configuration Options
Option 1: SW1 1-16: Close to clear password
Option 2: SW1 2-15: Close to recover BIOS
Option 3: SW1 3-14: Close to clear CMOS
Option 4: SW1 4-13: Close to update Managment Engine
Option 5: SW1 5-12: Close to set TPM physical presence
Option 6: SW1 6-11: Close to reset CIMC password
Option 7: SW1 7-10: Close to disable console
Handle 0x001F, DMI type 32, 20 bytes
System Boot Information
Status: No errors detected
```
We took too machines with exact spec and loaded them with 18.04 and
22.04 respectively to get the numbers for comparison.
### Machine Running 22.04
cpupower -c 31 frequency-info
analyzing CPU 31:
driver: intel_pstate
CPUs which run at the same hardware frequency: 31
CPUs which need to have their frequency coordinated by software: 31
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1000 MHz - 3.80 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 1000 MHz and 3.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.80 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
root@:/sys/devices/system/cpu/cpu31/cpufreq$
cat scaling_max_freq
3800000
We used a simple script to run `sysbench` and collect `scaling_cur_freq`
value.
```bash
Monitoring CPU frequency for core 0... (Sysbench PID: 1555682)
[56/67]
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 805.84
General statistics:
total time: 30.0005s
total number of events: 24177
Latency (ms):
min: 1.04
avg: 1.24
max: 86.92
95th percentile: 2.11
sum: 29982.32
Threads fairness:
events (avg/stddev): 24177.0000/0.00
execution time (avg/stddev): 29.9823/0.00
Sysbench test finished. Analyzing results...
--------------------------------------------
Frequency Statistics for CPU 0:
- Samples collected: 29
- Highest frequency: 2800 MHz
- Lowest frequency: 2585 MHz
- Average frequency: 2740.62 MHz
--------------------------------------------
```
No matter how many times we tried this, the value never breaches the
2.8ghz mark.
However, when the same tests were performed on a machine running 18.04,
the results were different,
```bash
Starting sysbench CPU load on core 0 for 30 seconds...
Monitoring CPU frequency for core 0... (Sysbench PID: 127486)
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 10000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1026.55
General statistics:
total time: 30.0009s
total number of events: 30801
Latency (ms):
min: 0.80
avg: 0.97
max: 19.09
95th percentile: 1.32
sum: 29984.49
Threads fairness:
events (avg/stddev): 30801.0000/0.00
execution time (avg/stddev): 29.9845/0.00
Sysbench test finished. Analyzing results...
--------------------------------------------
Frequency Statistics for CPU 0:
- Samples collected: 29
- Highest frequency: 3315 MHz
- Lowest frequency: 3078 MHz
- Average frequency: 3240.89 MHz
--------------------------------------------
```
As you can see it reached nearly 3.4ghz. We can confirm this behavior is
consistent as well.
Following are the Linux Kernel version we are running on respective
versions of the Ubuntu
uname -a (ubuntu 22.04)
Linux maglev-master-192-168-0-36 5.15.0-72-generic #79-Ubuntu SMP Wed Apr 19
08:22:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
uname -a (ubuntu 18.04)
Linux maglev-master-192-168-0-38 5.4.0-139-generic #156~18.04.1 SMP Thu Feb 23
08:50:29 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
We also confirmed that our machine doesnt run `thermald` due to
Unsupported Model on both versions.
Here are a few things we wanted to get clarification on
1. Why is this behavior observed?
2. What would be the way to mitigate this?
We also tried the following things to no avail
1. Set `intel_pstate=passive`
2. Set `intel_pstate=disabled`
3. Try setting the `scaling_min_freq` to `3ghz` and even then the
`scaling_cur_freq` was getting capped at 2.8ghz on 22.04 (5.15 Kernel)
The results were the same when those configurations were toggled as
well.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "lscpu.log"
https://bugs.launchpad.net/bugs/2117253/+attachment/5890832/+files/lscpu.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2117253
Title:
After Upgrading to Ubuntu 22.04 the CPU frequencies get clamped and
never reach the turbo thresholds
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2117253/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
