|
High CPU usage on 17.x kernels
I installed this on my system about a week ago (AMD Athlon X4 870K, A88X-Pro, 16GB) after using the stock kernels for Mint 18.3 for several months. Both the 4.17.0.8 and 4.17.6 kernels have the same issue--neither one is using any of the power-saving features on the CPU. The CPU clock stays in the 3.9-4.1 GHz range at all times, even when both Conky and System Monitor are showing very low resource usage. I booted back to stock 4.13.0.45 from the Ubuntu repositories and everything went back to normal, with clocks as low as 1700 MHz.
Back to top |
|||||
|
Show inxi -bxxxz so damentz has some idea of your system.
Back to top |
|||||
|
Booted into the stock kernel right now, but this is everything:
:: Code :: System: Host: john-desktop Kernel: 4.13.0-45-generic x86_64 (64 bit gcc: 5.4.0)
Desktop: Cinnamon 3.6.6 (Gtk 3.18.9-1ubuntu3.3) dm: mdm Distro: Linux Mint 18.3 Sylvia Machine: Mobo: ASUSTeK model: A88X-PRO v: Rev X.0x Bios: American Megatrends v: 2603 date: 03/10/2016 CPU: Quad core AMD Athlon X4 870K (-MCP-) speed/max: 1698/3900 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] Cayman XT [Radeon HD 6970] bus-ID: 01:00.0 chip-ID: 1002:6718 Display Server: X.Org 1.18.4 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1680x1050@59.95hz GLX Renderer: AMD CAYMAN (DRM 2.50.0 / 4.13.0-45-generic, LLVM 6.0.0) GLX Version: 3.0 Mesa 18.0.5 Direct Rendering: Yes Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI port: b000 bus-ID: 05:00.0 chip-ID: 10ec:8168 Card-2: Realtek RTL8192CU 802.11n WLAN Adapter driver: rtl8xxxu usb-ID: 002-002 chip-ID: 0bda:8178 Drives: HDD Total Size: 1748.4GB (50.2% used) Info: Processes: 193 Uptime: 2:24 Memory: 1044.0/15981.2MB Init: systemd v: 229 runlevel: 5 default: 2 Gcc sys: 5.4.0 Client: Shell (bash 4.3.481 running in gnome-terminal-) inxi: 2.2.35 Back to top |
|||||
|
When booted into liquorix, what's the output of, lsmod | grep cpufreq?
Also, if you end up getting a line for acpi_cpufreq, what are the values of all the values in: /sys/devices/system/cpu/cpufreq/ondemand You should see 45 for up_threshold, and depending on what the kernel believes your system behaves with IO, io_is_busy may be set to 1. Try setting up_threshold to 85 and io_is_busy to 0 and let me know if that helps. Just know that MuQSS behaves much differently than CFS, and is more likely to trick ondemand into choosing the wrong frequency when it bounces tasks between cores on your system, which is why up_threshold is set so low by default. You can adjust MuQSS to try preferring the original core over latency by setting /proc/sys/kernel/interactive to 0, but in my experience, this doesn't seem bias MuQSS much more than interactive, but it will cause weird delays if you set /proc/sys/kernel/rr_interval too high. Back to top |
|||||
|
I notice the same on my rather quirky MSI GP 63 Coffee Lake laptop. I used to be able to get it to scale up and down by choosing the conservative governor in cpufreq-governor, but now it sticks at 4 GHz until I suspend2ram and resume, when it works correctly. But this could just be due to a BIOS update that I applied at about the same time. A backported Debian 4.17.8 kernel using pstate doesn't "stick" with the powersave governor, though.
Back to top |
|||||
|
john@john-desktop ~ $ lsmod | grep cpufreq
pcc_cpufreq 16384 0 acpi_cpufreq 20480 0 up_threshold was set to 45 and io_is_busy was set to 0. As for the other values in that folder, ignore_nice_load and powersave_bias are at 0, sampling_down_factor is 0, and sampling_rate is 4000. I'll change up_threshold to 85 and see what happens. Back to top |
|||||
|
Didn't work. CPU still stuck between 3.9 and 4.1 GHz at all times.
Back to top |
|||||
|
Sorry for the delay, I've been periodically trying different settings, some that require me to recompile the kernel. One that made a difference on a laptop of mine was to disable nohz entirely.
Can you try booting with the kernel parameter, nohz=n, from your boot manager? The consequence of this setting means that the kernel will interrupt the processor every millisecond even while idle. In powertop you'll see lines like this, especially while idle: :: Code :: 12.8 ms/s 586.9 Timer tick_sched_timerOn my Latitude, I went from 1.5-2.5ghz using 0.9 volts in i7z down to 0.7 volts under 1ghz while sitting at the desktop with minimal applications open. As a bonus, my own CPU usage is lower. Can you confirm? I want to make sure this is not a hardware specific quirk. I also have another machine I need to test this with but I'll get to that in about 10 hours. Back to top |
|||||
|
Is this the same tweak that you applied to the 4.17-10 release?
Back to top |
|||||
|
Yes, that's exactly it. I tested this on more machines and periodic ticks gives enough idle samples to cpufreq + ondemand to reduces clocks on voltages on systems that can benefit from it.
For example, from my primary PC that built the Debian Sid kernel: :: Code :: $ inxi -C
CPU: Topology: 8-Core model: Intel Core i7-5960X bits: 64 type: MT MCP L2 cache: 20.0 MiB Speed: 3403 MHz min/max: 1200/3001 MHz Core speeds (MHz): 1: 3403 2: 1901 3: 1575 4: 1540 5: 1535 6: 1536 7: 1529 8: 1556 9: 2093 10: 1539 11: 1532 12: 1533 13: 1528 14: 1582 15: 1811 16: 1568 And then from i7z: :: Code :: Socket [0] - [physical cores=8, logical cores=16, max online cores ever=8]
TURBO ENABLED on 8 Cores, Hyper Threading ON Max Frequency without considering Turbo 3944.23 MHz (127.23 x [31]) Max TURBO Multiplier (if Enabled) with 1/2/3/4/5/6 Cores is 33x/33x/33x/33x/33x/33x Real Current Frequency 1595.24 MHz [127.23 x 12.54] (Max of below) Core [core-id] :Actual Freq (Mult.) C0% Halt(C1)% C3 % C6 % C7 % Temp VCore Core 1 [0]: 1595.24 (12.54x) 3.94 16.4 17.2 64.7 0 32 0.9225 Core 2 [1]: 1555.46 (12.23x) 3.96 12.4 8.92 77 0 28 0.9418 Core 3 [2]: 1563.39 (12.29x) 4.11 12.7 8.81 76.8 0 32 0.9368 Core 4 [3]: 1582.99 (12.44x) 3.66 11.4 4.12 83 0 30 0.9252 Core 5 [4]: 1538.68 (12.09x) 3.1 11.1 1.15 86.5 0 34 0.9348 Core 6 [5]: 1544.64 (12.14x) 3.54 11.4 2.41 84.8 0 30 0.9410 Core 7 [6]: 1539.59 (12.10x) 2.93 10.2 1 87.6 0 30 0.9396 Core 8 [7]: 1547.40 (12.16x) 2.89 10.2 1 87.6 0 32 0.9386 C1 = Processor running with halts (States >C0 are power saver modes with cores idling) I'm able to maintain lower voltages than I've seen in a long time while idle. Now obviously, a tickless kernel while idle would be preferred, but running lower voltages and lower frequencies is more important first. I'll explore my options next: maybe a lower tick rate and the high resolution patches as part of Con's CK patch set. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||