Page: 1, 2  Next

High CPU usage on 17.x kernels
pyjujiop
Status: Curious
Joined: 26 Jul 2018
Posts: 5
Location: Mount Airy, NC
Reply Quote
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
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3936
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Show inxi -bxxxz so damentz has some idea of your system.
Back to top
pyjujiop
Status: Curious
Joined: 26 Jul 2018
Posts: 5
Location: Mount Airy, NC
Reply Quote
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
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 763
Reply Quote
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
stevenpusser
Status: Contributor
Joined: 14 Jan 2017
Posts: 51
Reply Quote
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
pyjujiop
Status: Curious
Joined: 26 Jul 2018
Posts: 5
Location: Mount Airy, NC
Reply Quote
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
pyjujiop
Status: Curious
Joined: 26 Jul 2018
Posts: 5
Location: Mount Airy, NC
Reply Quote
Didn't work. CPU still stuck between 3.9 and 4.1 GHz at all times.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 763
Reply Quote
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_timer


On 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
stevenpusser
Status: Contributor
Joined: 14 Jan 2017
Posts: 51
Reply Quote
Is this the same tweak that you applied to the 4.17-10 release?
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 763
Reply Quote
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
Display posts from previous:   
Page: 1, 2  Next
All times are GMT - 8 Hours